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

IT support has left the building

Or at least it should have done.

How many users struggle with remote connectivity? Either functionality failures (why, after 20 years, are VPNs still so flaky?) or poor response times?

But does IT support understand? Well it’s sitting on a nice high bandwidth, highly available, low latency network.

So no it doesn’t.

It doesn’t understand the daily frustrations of users repeatedly getting timeouts, of going hours or even days without being able to establish a VPN and thereby access email and applications.

Is there a solution?

Continue reading