Thursday, October 1, 2009

Blogosphere: Duct Tape Programmer

Joel Spolsky is a famous blogger, partly because he knows how to get people so riled up that they'll talk about him... He's done that again which a recent post called The Duct Tape Programmer. As much as I hate to fall into his trap, the debate around this has been really interesting, so I'm gonna go ahead and talk about it!

The point of Joel's post seems to be in this quote from Jamie Zawinski:
"It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products."
Joel goes on to say that "Shipping is a feature. A really important feature. Your product must have it."

So, you have to ship a product to be worth a damn. Got it. Of course, the blogging world at large took his post as an attack on TDD, Agile development practices, and striving for Quality. This appears to me to be a classic case of Black Or White Disease. Either you are a "Duct Tape Programmer" who works fast and ships early but who's code is crap, or you are an "Architecture Astronaut" who over designs everything and never ships anything.

But this is not a black and white distinction. Richard Dingwall makes that point in Duct-tape programmers ship... once.

Ayende responds with disbelief that anyone would seriously suggest people abandon good practices in preference of relentless hacking just to ship a product. I'm not sure that was the message Joel was trying to send, though he was certainly saying that Unit Testing isn't worth the added cost.

Most of the debate therefore boils down to Quality, which I've touched on before in The Paradox of Quality. Quality is tricky. Jack Charlton hits on this by saying that quality is really just one dimension of many that must be balanced when developing a product. If fast to market with lots of features is a requirement, the only thing left to give up is quality.

But when you sacrifice code quality you are sacrificing product quality as well, and you are certainly adding long term cost. What shipped project ships once and never has to be dealt with again? Furthermore, what shipped product stays as simple as it was when it was shipped? If you sacrificed quality you're going to end up in a world of hurt when it comes time to dive back into that code and enhance it in unpredictable ways. But maybe the benefits of being first to market or shipping fast will mean that NOW you have the time to go back and raise the quality bar. Its harder to do it that way, but its not impossible.

This is what Domain Driven Design (DDD), and Test Driven Development (TDD) or Behavior Driven Development (BDD) is all about. Attempting to raise the quality of your code to the point where your product doesn't become legacy the day it is shipped (or even before its shipped...). But also attempting to do that without inordinate cost so that you can still ship your product.

This is about real world decisions with real world trade-offs. Developers don't like real world trade-offs, its part of what makes them good developers. They are given to all or nothing, Black Or White type thinking. Trade-offs are unpleasant and unwanted. But trade-offs come with real world issues, so as usual the answer of when to sacrifice some quality to ship a product earlier is: It Depends.

PS. This is the first post in a series of "Blogosphere" posts I intend to start where I write about interesting things I've seen out in the Blogosphere. If you like it, let me know!


  1. First off i like the format. It gives me a hand full of links to add to google reader (as if i need more crap to sift through) but thanks.

    Now relating to the actual topic.

    My take on it is this. Some people make their career by being the guy who endlessly advocates for quality, tdd, agile, etc. etc. Bob Martin comes to mind in this. His job is to be that "Clean Code" guy. I think every team, company, project needs one of these guys. He helps raise the bar and makes people think about things before they rush off and do a crap job on something in the name of "shipping."

    Other people make their career on being the uber-pragmatic "do what you need right now and nothing more" people. Spolsky is that guy. In "real life" we usually have a manager/business customer playing that role. They don't care about abstractions or unit tests or anything else we care about, they want to get it done and get it out. You also need this person because if they didn't exist it would take quite a while to get things done.

    Of course the real answer is (as always) somewhere in the middle. You need both roles and as a professional you really should know that and be able to play both roles yourself. If your on a team that constantly produces bad unmanageable code its time to put on the quality nazi hat and make people do things the right way. If you are 20 months into a 6 month project and haven't released anything maybe a bit of pragmatism wouldn't hurt.

  2. Well said Josh, I agree. When you have competing goals like this, it's good to have different people line up on fight the fight so you end up with the right compromise for your situation.