Unit testing code - don't bother

Joel Spolsky has written an excellent piece called The Duct Tape Programmer. In it, he quotes Jamie Zawinski, who is what Joel calls a duct tape programmer say "(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."

Most serious projects start off with unit tests as an important part of the development activity. Many managers insist that unit testing code be written even before the actual code. Gradually, however, as deadlines approach, unit tests are ignored. They lie untouched, reflecting the functionality as it was envisaged initially. Eventually, nobody has the time to update them. Which means that the effort spent to write them in the first place was a major waste of time.

I have never seen a real-world project in which the unit tests were meticulously maintained and used to the desired effect. It is merely good to say "We have unit testing code". It is entirely another story to actually have meaningful unit testing code.

They are simply not practical in the kind of projects we have today. Well, I am talking about the projects that most people work on. Software for critical projects like the Chandrayaan, for example, is an entirely different ball game. A single mistake in the code could have blown the mission. But not in the projects that you and I work on. Where deadlines are important.

So, here's my advice to software programmers and managers: don't bother with unit testing code.