The following is a direct transcription of some tweets from November 20th.

TDD. By which I mean the thing where you write a tiny test, see that it doesn’t run, write just enough code to make it run, refactor the code to remove duplication and add clarity, repeat until done.

Why do we do that?

One word: productivity. A few words: most cost-effective path from here to done.

It’s not about beauty, craft, a sense of pride, although it can provide all those things.

It’s about using the most productive approach to getting our whole job done.

Why, you might ask, is it the most productive way? It sure does feel slow! Let me count some ways.

  1. The code always works. We’re never in that state where the thing almost works and we’re not quite sure why it doesn’t always work, or not quite sure even whether it works.

  2. The code is well-designed and that helps us go fast. We can deliver more goods, faster, over a smooth road than over one riddled with potholes and detours. TDD keeps the road smooth.

  3. We can find what we need rapidly, and change it easily if we need to. Everything appears once and only once, and is cleanly separated out. Modularity works, speeding our reading and adjustment of the code.

  4. That’s not slowness you feel, it is smoothness. The fastest driver, the fastest runner, the fastest swimmer is, above all else, smooth. No wasted motion. TDD keeps us from wasting motion.

Add your own observations and think about them. TDD is about productivity. It’s about delivering the most working code per unit time and unit dollar. (Currency conversions provided elsewhere.)

TDD is about time and money.

It also feels really good. Whee!

The not entirely venal GeePaw Hill suggested these two links to his work relating to this subject: Five Underplayed Premises Of TD and TDD & The Lump Of Coding Fallacy. I’m happy to recommend them here.