Test Driven Development more than doubles the lines of code you have to write. With all that extra code to write, where will we ever find the time?! We have deadlines!
Lines of code has always been a bad metric; why bring them up now? Error-free robots, programming at a constant rate, might have to be concerned. But people are neither error-free or program at a constant rate. Does it matter that the LOC count doubles? The time consuming parts of programming are: thinking, problem solving, and confirming solutions.
In my article The Physics of TDD I compare two programming techniques: Debug Later Programming and Test Driven Development. I model how TDD shortens the time to mistake discovery to near zero. When you are immediately notified of a mistake, you can fix it immediately. If that same defect went undetected, as it does in DLP, it would lay dormant waiting to cause trouble.
DLP has less code (about half) and more bugs, while TDD has more code (about 2x) and less bugs. When I do TDD I find that I make subtle mistakes quite regularly. Many times an hour, but find them immediately. Each of those mistakes would have cost me, or someone, future find and fix time.
Let’s try a little thought experiment. I’ll write production code for a couple hours without TDD. Let’s go easy on me and say I only mess up 5 times per hour. After two hours of code writing, I manually test the new production code (which takes time), and almost fix all the problems. For the fun of it, say that one mistake every two hours goes undetected, and is later reported as a bug.
What does it cost to find and fix that buried mistake? Well that depends on the mistake. How long does it take you to find and fix a bug? Tough question to answer.
According to a defect study at Hewlett Packard (described in this paper), defect repair times have a distribution as described in this table:
|Defect %||Time to find and fix||Time %|
It’s just one study, but let’s roll with it. Being very conservative, let’s say the bugs left behind are the easy ones, and only take 2 hours to find and fix. If that 2 hours of effort could have been prevented by writing two hours of TDD style unit tests, I’m even! Actually, I am ahead of the game because I would not have spend that manual test time. If any of the defects were more difficult to find and fix (like the other 75% of the defects), I am way ahead of the game!
Doubling the lines of code does not slow me down.
TDD will slow you down while you are learning it. Also, I am not saying TDD will prevent all bugs. You will still have bugs, but fewer of them.