So the fires continue to burn, as Joel Spolsky’s internet access hasn’t been disconnected.  For someone who is supposed to be an idiot and irrelevant, a lot of people still read and link to him.  I guess one guy is corrupting all the new developers, who are assumed to be reading Joel’s every word but in reality these developers probably didn’t know he existed until all these people linked to him saying he was wrong.

The lastest outrage seems to be this question on Stack Overflow: Why do I need an IoC container as opposed to straightforward DI code?

Now, before we get into the flames, let’s take a moment to actually look at the real question.  The use and benefits of Dependency Injection are not in question – not even by Joel.  The author has taken time to use the currently popular IoC and DI frameworks for his platform.  He is looking to understand the trade offs involved with using a framework and having to train his co-workers, and increasing the number of project dependencies.  Now, Joel’s response included:

The most valuable benefit of using an IoC container is that you can have a configuration switch in one place which lets you change between, say, test mode and production mode. For example, suppose you have two versions of your database access classes... one version which logged aggressively and did a lot of validation, which you used during development, and another version without logging or validation that was screamingly fast for production. It is nice to be able to switch between them in one place. On the other hand, this is a fairly trivial problem easily handled in a simpler way without the complexity of IoC containers.

Of course, we will ignore this sane and rational portion and focus on the one line zingers like:

I'm with you, Vadim. IoC containers take a simple, elegant, and useful concept, and make it something you have to study for two days with a 200-page manual.

...

I believe that if you use IoC containers, your code becomes, frankly, a lot harder to read. The number of places you have to look at to figure out what the code is trying to do goes up by at least one. And somewhere in heaven an angel cries out.

Never underestimate the power of developers to focus on a leaf in the middle of a forest.  In my view, this forest is using a framework versus using a pattern.  You could have DI by using Ninject (which I highly recommend to anyone looking for a DI framework), or you could roll your own DI (which I do quite commonly).

To many, these are mutually exclusive options and that one choice is always better.  This violates a core tenet of Agile – that we embrace change.  Each project should have a discussion if a framework is right for that project and that the decision is not permanent.  This extends beyond DI/IoC to every framework or line of code in the project – is it better to use an existing solution or roll our own?  There is no universal right answer here except “It Depends”.

Critical thinking and dissent on your team is a requirement for success.  If everyone accepts conventional wisdom (or worse, internet wisdom) without question, you might as hang up a sign that reads “because it’s always done that way.”