TDD is cheaper

Cover image: Scene from Modern Family, Phil: "Slow is smooth & smooth is fast!"

Tim Ottinger posted this article: Do They Hate Writing Tests?

As always, concise & to the point. I had the same experience with all 3 types of code: Old legacy, new legacy & test-driven.

What I found very revealing in the article is this list of new-legacy activities:

1. Write a bunch of code (being very careful, of course)
2. Edit it until it will compile.
3. Debug it until it gets the right answers.
4. Look it over for other errors and correct them.
5. Send it off to code review

Here is what I think the TDD list of activities looks like:

1. Test-drive the code (no need to be careful, tests watch your back)
2. Edit it until it will compile. for TDD-ers working in compiled languages, compile fail is a failing test, so we don't have more than one line compile failures and we fix it immediately
3. Debug it until it gets the right answers. we test-drive, so bugs are few and far between (like, maybe 1 per month or less)
4. Look it over for other errors and correct them. no need no errors - all tests ever written are run often (faster ones more often) so nothing is broken for more than a couple of minutes
5. Send it off to code review ... sure, we can do that (but check out Refinement Code Review by Martin Fowler)

Ah, sorry, I'll remove the superfluous items:

1. Test-drive the code
2. Send it off to code review

Hmmm, this list seems smaller than the new-legacy list. Could it be that writing code using TDD designing your system driven by tests is more efficient, thus cheaper? Remember, the most expensive thing in IT is the developer hour.

I've heard first-hand accounts of TDD projects being FOUR (4) times as efficient as non-TDD projects.

Granted, TDD takes practice, but doesn't everything?