Can you afford not to use TDD?

Test-driven development (and test-driven design, behavior-driven design, acceptance test-driven development, etc.) have been around a while. One might say that it was started (or “rediscovered“) in 2003 with the publication of Kent Beck’s book “Test-Driven Development By Example.”

Whilst there are purist arguments about whether strictly adopting TDD is the best approach, there are few arguments about whether it is wise to adopt the general philosophy. Why? Because the earlier a defect is detected, the cheaper it is to fix it.

In Code Complete: A Practical Handbook of Software Construction, Steve McConnell provides estimates of the cost to remediate a defect in table 3-1 “Average Cost of Fixing Defects Based on When They’re Introduced and Detected” (page 29 in the second edition of the book, near the beginning of chapter 3).


This table makes it pretty clear that non-coding bugs need to be detected before coding begins, and coding bugs need to be detected before a project reaches the system test stage. From these points hereafter the cost of defect resolution rises drastically.

So how does one ensure that defects are detected at these early stages? Continue reading