Duct Tape Programming

Joel tells the story of The Duct Tape Programmer, and Uncle Bob offers his response. Now these are two pretty smart guys who know a lot about software development. But when we receive fundamentally different messages from a couple of industry luminaries like Joel and Uncle Bob, we’re left wondering – “Who is right? Who should we listen to?”

Joel makes some valid points, but it’s strange that immediately after discussing the dangers of overengineering and the importance of shipping the product, he points out the following:

Zawinski didn’t do many unit tests. They “sound great in principle. Given a leisurely development pace, that’s certainly the way to go. But when you’re looking at, ‘We’ve got to go from zero to done in six weeks,’ well, I can’t do that unless I cut something out. And what I’m going to cut out is the stuff that’s not absolutely critical. And unit tests are not critical. If there’s no unit test the customer isn’t going to complain about that.”

I’m not quite sure how unit testing encourages overengineering nor how unit testing impedes shipping the product. Unit testing does neither. In fact, unit testing inspires a simpler design, not a more complex one. And because unit testing helps developers build quality into the product, I’m certain it doesn’t inhibit shipping the product – or at least a product that works. The correlation makes no sense, and I can’t help but wonder if the message wasn’t an intentional jab based on some past conflicts.

Of course, I certainly agree that favoring simplicity and getting the job done are righteous goals. Sometimes you have to cut a few corners, take a few shortcuts, and implement a solution that isn’t perfect. But there still exist fundamental practices of professionalism that must serve as our guide. And as Uncle Bob points out, unit testing is one of these practices. Bottom line! As a humorous post on twitter suggests:

never take software advice from a bug tracking system salesman

Unit testing is important, has significant long-term benefits, and developers should use them. However, I do take slight issue with Uncle Bob’s following statement:

I found myself annoyed at Joel’s notion that most programmers aren’t smart enough to use templates, design patterns, multi-threading, COM, etc. I don’t think that’s the case. I think that any programmer that’s not smart enough to use tools like that is probably not smart enough to be a programmer period.

In this respect, Joel is right. There might be a lot of people out there who aren’t smart enough to be programmers, but the reality is that only 50% of us can be above average. Of course, we all think we’re in the upper 50 percentile and when we’re looking at code written by someone else, it’s apparent to us it’s the other guy or gal who’s in the lower half. Without arguing who belongs where, the reality is that if we were all smart enough to use these advanced constructs, we wouldn’t be left with the mess we have today.

But really this only reinforces the importance of unit testing, which is why statements that denounce unit testing are so surprising. Think about it…Would you rather maintain a codebase with near 100% test coverage or a codebase with near 0% test coverage? Maybe those who can’t answer this question are the folks that shouldn’t be programmers!

9 thoughts on “Duct Tape Programming

  1. That’d depend on the codebase.

    I’d rather have a well-written, clear, concise, elegant codebase with no tests than a pile of crap with 100% coverage–especially if the tests don’t test what they need to be testing.

  2. It has been some interesting posts. Generally I tend to take Joel’s stuff with a grain of salt, he has showed on numerous occasions on StackOverflow that he does not hold back his opinion even if he has no idea.

    I am curious about your statement that in reality only 50% of us can be above average. By inference then the other 50% of us are below average and that leaves none who are average?! lol

  3. @Dave,

    I will be curious to find a crap code with unit tests. Sorry but IMHO unit test frequently point out design flaws in your code and hence produce better code.

    Great blog by the way Kirk.

  4. Why not try test driven development? It’s like the so aptly named “Duct Tape Programming” but you’re forced to design better.

  5. Unit Testing only impedes shipping the product when project time does not include time for unit tests. I can’t remember how many meetings I have been when someone estimates X hours, then later on corrects themselves to add in time to unit test.

    Unit testing is new to a lot of people, and it takes time for people to remember to include it in their estimates.

Leave a Reply

Your email address will not be published.