Using IoC Containers in anticipation of Application Extensibility

Question

I know there is a similar question Here But I think mine expands on this a bit more.

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.

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.

My specific question as I move forward is:

1. 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.

2. Is it a sign of poor design if implementing a container when extending an application beyond its original intention becomes cumbersome?

EDIT:

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.

Answer 1

I'm a big fan of Clean Code and especially YAGNI. "You ain't gonna need it". If you don't need DI in a project, don't use it. If you need DI for Unit tests but don't need a container, don't use one. Simplicity is a virtue of it's own. Keep it as simple as possible.

If preparing a project for future extensibility costs time or money now, don't do it. You can pay that in the future. Because that future may never come. And if it does, it certainly will not be as predicted and your preparation will be not as useful as you thought.

I've been in projects where there was so much "extensibility" code, that you could have deleted at least 75% of the source code and all required functionality would still have been there. I have no problem envisioning the project manager wondering what the hell took so long to implement such a basic functionality. Don't do that. Plan your project, get your requirements and implement them. If extensibility is a requirement, plan it, estimate it, let your managers know. My guess is they don't want extensibility that badly. They'd rather have another working program instead.

That said, obviously you are learning. If it doesn't cost anything in terms of time or money, go ahead and develop your next program so it can more easily be extended. Just keep an eye on the cost.