The State of Spolsky or: How I Learned to Ignore the Legacy Programmer Boss.

If you don’t know who Joel Spolsky is, you can probably pass on this blog entry. I have a ton of respect for Joel. I’ve learned a lot from his posts over the years, and I still consider him to be a guru in the business of software. I’m sure I'll continue to learn from him yet.

In recent weeks, Joel has made some controversial posts regarding what many people think are the hallmarks of modern programming (design patterns, TDD, IoC, etc…). In this blog post, Joel espouses the ethic of the “Duct Tape Programmer”. In this stackoverflow.com answer he has this to say about IoC:

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 personally am perplexed at how the IoC community took a beautiful, elegant article by Martin Fowler and turned it into a bunch of complex frameworks typically with 200-300 page manuals.

I try not to be judgemental (HAHA!), but I think that people who use IoC containers are (A) very smart and (B) lacking in empathy for people who aren't as smart as they are. Everything makes perfect sense to them, so they have trouble understanding that many ordinary programmers will find the concepts confusing. It's the curse of knowledge. The people who understand IoC containers have trouble believing that there are people who don't understand it.

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.

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.

I see two things happening here:

1. Joel continues his (very worthwhile IMHO) crusade against the “Architecture Astronaut” who is so far into the clouds that they aren’t writing code anymore but think they should tell people how to code, and the “shiny new toy” developers who have a solution looking for a problem. I’ve had very painful experiences with both of these archetypes.
2. Joel inadvertently enters “Legacy Programmer Boss” territory as he discounts mainstream changes in programming that have happened since he stopped coding as his primary job.

The Legacy Programmer Boss is the manager who had a successful programming career in the past but sees many modern concepts as language baubles, academics, and anti-patterns because they are out of the loop. The fact that they once had a high degree of expertise gives them confidence in making mis-judgements.

There was a point in time where “design patterns” where purely academic. However now-a-days many design patterns have become as ubiquitous as the FOR loop (that was the idea behind defining these patterns). IoC is not difficult to understand by any developer who can understand the factory pattern. Frankly, the average developer can go to 0 – 60 with IoC by watching a 22 minute video from David Hayden. If a developer cannot understand the factory pattern, then they are doomed to be a duct tape programmer. I’ve worked with many duct tape programmers, and over time their code requires more duct tape.

Joel is justified in his efforts to decry the Architecture Astronaut, but his Duct Tape Programmer is just as bad. After years of experience in the field, I think Uncle Bob’s Clean Coder / Software Craftsman is the happy medium.

If you write software for a living, you should keep up with the current practices and use them as you see fit. If you see your opinion in the minority, you are either a genius, an early adoptor, or wrong.