title: Using IoC Containers in anticipation of Application Extensibility
body: <p>I know there is a similar question <a href="https://stackoverflow.com/questions/2551010/when-to-use-an-ioc-container">Here</a>  But I think mine expands on this a bit more.</p>
  
  <p>I have recently been working on an Application that has been in production for about a year, with no issues and no real plan for extension.  The application had few dependencies and used DI but without a container.  </p>
  
  <p>Now I am extending the application to a much broader scope at the company's instruction, this led me to implement the use of an IoC Container.  The issue here has been the overhead of adding a container to code I previously thought would not ever require one.</p>
  
  <p>My specific question as I move forward is:</p>
  
  <ol>
  <li><p>When planning and coding smaller applications that presumably will not expand much, should I implement a container in anticipation that scenarios such as these may present themselves and in such anticipation I would be better off implementing a container from the start so upon extension the framework already exists.</p></li>
  <li><p>Is it a sign of poor design if implementing a container when extending an application beyond its original intention becomes cumbersome?</p></li>
  </ol>
  
  <p>EDIT:</p>
  
  <p>I am using solid principles (to the best of my ability) and interfaces extensively in my applications currently, the question is more related to the use of an IoC Container, not DI in and of itself.  The application mentioned before is a roll-your-own DI style that I am adding a container to which is where the question arose.  </p>