by Aslam Khan

The software craftsmanship movement have been religiously punting the value of TDD and refactoring as agile tools, making code quality the goal in agile software development. Yet, the cost of  TDD is never discussed.

With a greenfield code base, using TDD as a design tool is tough because design is tough. With a legacy code base, it is even tougher because TDD becomes an analysis tool too. Whilst TDD and refactoring are essential tools, they operate in a narrow range that is the intersection of scope, clarity and frequency of releases. Outside of this range, TDD comes at a significant cost. After all, it is not that the absence of tests that makes a code base a legacy code base, but the moment of first release. Once released, all code is just one requirement away from being invalidated, and TDD cannot fix that.

I base this session on projects that I have worked on to show when TDD can cost you more and what practical alternatives exist. I will show how to use technical debt as a tactic, not a measure of failed craftsmanship. This session, in truth, balances out the practicalities of delivery with craftsmanship.

Aslam has been building software for long enough to make peace with the fact that software design is ridiculously difficult. He has taught and coached far too many developers over the years in TDD, refactoring, design and other aspects related to software development. He speaks fairly regularly at software development conferences locally and internationally. At the moment a fair bit of his time goes into writing the book Grokking Functional Programming published by Manning. And when he doesn’t have enough to do, he blogs at