Software Engineering is such a nascent practice that we have very little that we can point at for facts, and instead spend much of our time listening to circumstantial evidence from developers who have tried and had success with different tools or techniques. And at the same time, since we don’t have an infinite amount of bandwidth to try everything for ourselves, we will often listen to other developers that we trust when they say that something is not good or adds needless complexity.
Now, there are some developers take the time to carefully evaluate and think about all of the tools and practices that come there way, but just like in every industry, there is a vast majority who do not put this kind of thought and work into their endeavors. This is something that is to be expected almost everywhere though, you have a small piece of the overall populace who puts in more work, has more insight, and who shares this knowledge, and they are looked at for leadership and guidance by the majority. You know the kind of people that I am talking about, the Martin Fowlers, Bob Martins, and Kent Becks of the world.
But we can’t rely on those people for all of our technology advice because as much as they produce, they still couldn’t possibly fill the void of knowledge out there. And so we read blogs (like this one!), scour the internet, and use useful sites like stack overflow.
Honestly, I probably wouldn’t think of using stack overflow for programming advice, since I mostly see it as providing answers to purely technical questions, but it appears that at least some people do use it for this purpose. Which is why I was quite intrigued when my friend John Feminella tweeted this link to a post on stack overflow where someone was asking why they needed an IoC container instead of just doing manual injection.
If you skip the responses and head right to the end you’ll see a post by the “creator” of stack overflow, Joel Spolsky. Now I realize that over the years Spolsky has devolved into nothing more than living, breathing, walking, flamebait, but so many developers still listen to what he has to say. And with good reason, he has become incredibly successful creating a software development company which hires tons of smart people and produces what many consider to be a great product. He even has the “Joel Test”, which is a twelve point list about software best practices. If we lived in a vacuum, and you didn’t have to read constantly about some crazy statement he made, then you might be surprised to hear something like this come out of his mouth:
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.
But unfortunately, this is exactly what I expected out of him. Anyone who has sat down with a modern IoC container for more than 5 minutes will know that this is a complete load of crap. Joel has clearly never worked with an IoC container and is instead happy to spread FUD so that he doesn’t have to bring his software engineering skills forward. Instead, he pretends to move forward, and by doing so, holds many developers back. And that is dangerous.
Thankfully, if you go up to the top of the list of answers, you will see that the number one answer is from someone that I greatly respect, Ben Scheirman. In his post he carefully explains why an IoC container is beneficial and thankfully the power of stack overflow pushed his answer to the top and Joel’s answer to the bottom.
Unfortunately though we don’t always have this kind of filter implemented for us. We have to look at a blog post or technology and make the call for ourselves whether or not we are going to agree with it. We just have to make sure that we actually think and analyze, instead of agreeing because it is easier, convenient or more comfortable for us to do so. We have to make sure that we don’t fall prey to those who pretend to move forward, and instead listen to those who are sincerely trying to find a better way.
And as a final pièce de résistance: For all of those people out there who are scared of IoC containers, check out this (via Ninject):
public class DefaultModule: NinjectModule
{
public override void Load()
{
Bind<ILoginService>().To<LoginService>();
}
}
And this:
public class DIContainer
{
private static StandardKernel kernel =
new StandardKernel(new DefaultModule());
public static T Resolve<T>()
{
return kernel.Get<T>();
}
}
And now:
ILoginService loginService = DIContainer.Resolve<ILoginService>();
See? That wasn’t so hard!
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.
An ad hominem attack on Joel and his readers. Ugh.
[quote]Developers who pretend to look forward[/quote]
Brilliant one line summation of the problem.
Justin, the nub of your article is about developers (or, in the more general case … people) who choose to pretend to "move forward" and by so doing (inadvertently or otherwise) keep others back.
If I may be so bold – Joel is no longer a developer, he is now firmly entrenched in the land of marketing. Given this – is this not just a cunning tactic for gaining mindshare for SO and the new associated SaS Q & A offering?
I’m not attacking Joel, or his readers. Surely you aren’t going to argue that Joel says things for nothing other than shock value. And in this case, the wisdom of the masses seem to agree with me. I’m not disagreeing with Joel because he is Joel Spolsky, but instead, I am disagreeing with him because he based his claim on false assumptions.
Had he questioned the validity of the practice of using DI containers, then there would have been nothing wrong. I know many people that question their benefit. But for him to simply make things up to prove his point seems a bit much, and in my opinion, deserves to be questioned.
@Eric I would agree. But I guess "Developers or people whom developers turn to for development advice" was a bit long winded. 🙂
And yes, I am pretty sure that Joel says many of the things that he does just because it attracts attention. And yes, I am falling prey to it. But if I can help dispel one myth surrounding DI to even one person, then it was worth it.
What a shame. I think Joel’s old articles are great, I owe him a lot of credit. However, he really should either start programming again, or keep quiet. His information is simply out of date, and he doesn’t get it.
Honestly, it’s a sad realization for me. The beginning of the end was when he starting criticizing unit testing, when he clearly didn’t understand it.
@Andy If Joel is wrong and his readers are misled, then correction is justified. If you believe that any counter argument is an attack on the person, then you are simply mistaken.
Excellent post, Justin.
++Alan
@Justin,
Everybody has a right to express their own opinion. Thus, Joel has just told what he’s thinking. It’s neither good nor bad.
You just shouldn’t forget about using your own brain when reading Joel.
At the same time, seems like some people are just jealous of Joel’s success who can easily put his thoughts and express his thoughts without boring his readers.
@Jason Agreed, Joel is a very smart guy, and when he is talking about things that are in his sweet spot then he can produce some great material.
@Alan Thanks, I try not to attack people directly, and I hope this post didn’t come across like that. The only part that might is the flamebait comment, but seriously, I can’t be the only person who feels that way 🙂
@Mike His opinion isn’t good or bad. But when he says that IoC containers take 2 days and 200 pages of a manual in order to use, that isn’t an opinion, that is just false information. He is using FUD to support his opinion that IoC is overkill. I am okay with him believing that IoC is overkill. I am not okay with him scaring people away from IoC by telling them that it takes a genius to figure out a container.
@Mike Just because Joel has a right to express his opinion doesn’t excuse him from forming an opinion with no understanding or experience. Joel is wrong, at least in this case. If you care to argue otherwise, I’d love to hear your case.
I don’t know anyone in the industry that doesn’t admire Joel’s success in creating a successful company. That fact doesn’t mean we are jealous when we call him out on his BS.
++Alan
I see where you are going specifically with JS’s comments on SO. But in general, are you saying that developers that do not use a (mainstream) framework such as Spring, NInject, Unity, etc. also are pretending to look forward? I ask this in the context of a recent blog series I have started around dependency management:
Part 1 of 3
http://blog.softwareishardwork.com/2009/09/dependency-management-for-rest-of-us.html
Part 2 of 3
http://blog.softwareishardwork.com/2009/09/dependency-management-for-rest-of-us_16.html
Part 3 of 3
(coming soon)
In my current project and any other project I manage, I would not instantly gravitate to a mainstream IoC/DI implementation for the sheer fact that I am trying to not only reduce coupling, but also complexity. Granted, in your NInject sample you demonstrate a simple use case; I have seen projects leverage as many features that <insert container framework> can provide. I advocate for proper and pragmatic dependency management. If that means using a mainstream framework because of a specific set of technical requirement, then so be it; if it means rolling your own (or using a non-mainstream simplistic implementation) then this is fine too in my book. A developer that is educated enough to be able to confidently make this call, defend it, and run with it is, in my opinion, truly “looking forward”.
@D.P. My only point was that saying "IoC is easy, but you don’t want to use it cause all of those pesky IoC containers are so hard", is simply a red herring.
IoC is a simple topic that is not so simple to apply appropriately. But Joel’s statement just spread undue fear of DI containers in general, and that is what I had a problem with.
Honestly, I don’t care if you don’t like DI, or want to build your own container, but advocate for your opinion based on logic and experience, not on hyperbole.
Justin, excellent article, and I think a very necessary article as well. I enjoy (even as flamebait) Joel’s articles, but I’m going to go out on a limb here and say that he’s somewhat responsible for the information he posts. Opinions are fine, but when someone with as much clout as Joel has gained over the years uses false information to back up a claimed fact, I think they are being irresponsible.
You know, it’s pretty entertaining to read Joel’s books and blog posts. But it also appears to be very amusing to read the arguments against his statements. Joel just acts as a successfult troll, while many of you just got pissed by him.
Since many people including his opponents think of Joel as a very influential person, he just can post anything, even just an article consiting of just an f-word and I believe many bloggers will start to argue with Joel, while he’ll just have a good laugh.
@Mike I agree, and it is always a difficult call on whether or not to draw attention to statements like that. And believe me, I am not delusional enough to think that Joel even remotely gives a crap about my blog post. 🙂
@Justin,
So, isn’t it easier to just ignore his statements?
@Mike Easier? Maybe. Less fun? Definitely. 🙂 But in all seriousness, I think it important for people to hear dissenting opinions, especially when it comes to opinions as high profile as Joel’s.
Good article.
@Justin re: "delusional enough to think" comment – Warning! Incoming joelonsoftware.com attack on IoC/DI! I can feel it.
Metaphorically speaking Joel has a very big soapbox and a megaphone to spread his beliefs. While I agree that you should read his articles and use your brain, I also appreciate it when I don’t have to defend my brain to read an article. Reading Joel’s more recent posts automatically triggers my FUD sensor.
"Moving forward" is a subjective statement. When the current state of technology changes in a matter of 3 or 4 months and something BETTER than IOC is available and in use would you chastise someone who waited for the ultimate solution to a problem as opposed to the penultimate? Take care with the arrogance of claiming what is good and just and "moving forward" for we are all fallible in the forge of technical evolution. btw – I don’t even know who Joel is (nor do I care) but painting his opinion as unfounded because he has reached a certain pinnacle of success is not just – maybe he does still code and has a valid opinion – how would we know?
@Tahbaza Of course IoC will be replaced. In fact I firmly believe that IoC containers are an artifact of the limitations of our languages. What I do know, is that those who are not looking for the intermediate solutions are not the ones who will find or accept the later solution.
And one last thing, there will never be an ultimate solution.
You are so right. And Joel Spolsky is obviously completely and utterly RONG.
There really should be some kind of “driving” licence for people who want to program a ‘puter. And first on the licence exam should be to check that the prospective punter knows how to use an IoC container. You’re not a *real* programmer unless you know this stuff! You’re just a quiche-eater n00b that should bow before us real men to be gratefully spat upon from our high pedestals of obvious intellectual superiority.
I mean, without DI / IoC you can’t do TDD. Imagine mocking and stubbing a CQRS repository-based SOA over an XML RPC with an MVC UI without the IoC injecting AOP style patterns dynamically using the SCC source provider binding and tested via nUnit and you will see what I mean. Can you believe that their are dunderheads who are so ignorant of all this? They are so stupid. They make me laugh. I enjoy pointing at them and laughing. Occasionally I fantasise about urinating up their trouser legs when mummy is out of the house.
Listen up all you dirty unwashed n00bs! IoC is EASY. It takes mere MOMENTS to acquire a deep and thorough understanding of constructor, property and method injection, the pros and cons of each, and auto wiring (you don’t need to know how it works under the hood, it’s better to think of it as like a magic moonbeam for your code). Object lifetime management was intuitively immediately obvious to me because I’m so clever. If you worry about things like IDisposable objects with respect to lifecycle management then you’re just being anal-retentive (please observe that I’ve hyphenated that term properly – unlike so many morons). Again, it’s best viewed as the 2nd magic moonbeam pillar. Implement your cross-cutting concerns with the Interception facilities provided by the IoC container but don’t worry too much about what that means or why I’d want to do that. It’s obvious because you already know about concepts of loose coupling and favouring composition over inheritance. If you don’t you have no business owning a computer and should get back to flipping burgers right *now*, you filthy peon untermensch.
Anyway, if you do hit any pain points with an IoC container, it is always, ALWAYS easily resolved (hahaha, I’m really witty, too). I recommend a standard guideline whereby you call the IoC Resolve method to construct child dependencies in each and every constructor. This way, trickier design issues seem to resolve themselves. Obviously this is the most flexible way to use the container. The simple solution is often the best, and over-engineering is just another form of stealing from your customer.
Any half-decent programmer should take NO LONGER than TWO MINUTES before they are CERTAIN that they know ABSOLUTELY EVERYTHING there is to know about how IoC containers work and KNOW how to use them properly. If it takes you any longer than this then you are DUMB, a WORTHLESS LOSER THICKO and a COMMUNIST. I bet you smell of wee, too.