Test-Driven Development, or TDD, is the practice of writing tests, then code, in short iterations of a few seconds to a few minutes.

A common trope I hear coming from some moderate TDD detractors, is that TDD makes sense, when you’re willing to wait long enough to reach the break-even point.

This sounds reasonable on the surface. We routinely calculate the break-even point or payback period for any thing that requires a large up-front investment for a long-term pay off.

In this way of thinking, the TDD break-even point can be visualized with a chart something like this:

Unfortunately, this calculation is completely wrong, where experienced TDD practitioners are involved. This is because TDD makes development faster.

A more accurate view is something like this:

I wrote a lot more about this in a long-form blog post if you’re interested.

A few weeks ago, I had a good conversation with George Stocker about TDD on the Tiny DevOps podcast. Have a listen.