The Duct Tape Programmer (is unit testing necessary?)

A few weeks back I noticed an interesting posting on the Joel On Software blog by Joel Spolsky. Entitled The Duct Tape Programmer, the post was a reflection from Joel after having read Peter Seibel's recent book Coders at Work. The book is an interesting read and is a collation from Seibel's interviews with 15 "all-time great" programmers. One of those programmers is Jamie Zawinski - an early member of the Netscape development team (now a nightclub owner).

In Spolsky's post, in between a few expletives(!), he highlights Zawinski's positive attitude to getting the product out of the door:

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

Spolsky also highlights Zawinski's more challenging approach to testing:

[Unit tests]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 find the last sentence to be the most challenging. And it seems I wasn't alone. In a subsequent post on his own blog, Peter Siebel went into detail about his 15 interviewees' attitudes to unit testing (and test-driven design). It seems that attitudes were mixed.

As I suggested in my previous post entitled "Who Makes the Decisions to Cut Corners?", the customer will see the impact of reduced testing, and hence I believe that the customer is (should be) interested in unit testing. I don't suggest that your non-techie customer needs to be aware of the detail. What I say is that the development team should be able to offer a reliable estimate of how long each of the steps in the development process will take (including peer review and unit testing), and they should know the benefits of them and the business impact of reducing them. In circumstances where it is suggested that unit testing (or peer review) be reduced, the development team should be in a position to explain the business impact of making such a change, thereby empowering the customer to make a commercially-based decision.