Lately, there’s been a thread of discussion that centers on the question “Is TDD dead?”
TDD isn’t dead, nor is it the problem. TDD is a practice, a tool. It’s like a hammer. We can use TDD to build something marvelous, and we can use it to build something horrible. Unfortunately, TDD gets a bad rap because many have been vocal about using it to build software that ends up being undesirable. That’s sad, because under the right circumstances TDD can be used to build fantastic software. I’d hate to see developers abandon it altogether.
Declaring TDD dead is the consequence of continuing prescriptive, ideological arguments. Fortunately, the ensuing discussion has been a good attempt to get at the heart of the problem. The heart of the problem is that this marvelous practice, along with many others, are so quickly enshrined into moral arguments about how one should act, when creating software. If we return to principles, instead of dictating practices, it’ll come as no surprise that TDD, unit testing and other practices aren’t universally applicable.
At the end of the day, software development exists to create value for customers. This, if anything, is all we want to prescribe. If we look at TDD as a means to the end of creating valuable software for our customers, then we’ll have a framework to decide when it’s not adding value and when it is. Likewise with unit testing, pair programming, continuous integration, test code coverage and many other practices we all too often prescribe. If we start to describe these practices as a means to an end, we’ll be able to establish when they are conducive to an end, and when they aren’t.
I sought TDD as a means to produce better software. I didn’t arrive at TDD from the perspective that I was developing software wrong, all along. I wanted to understand what it would enable me to accomplish. I tried TDD on everything. It didn’t take long to realize it had limitations. This insight was invaluable.
If you’re new to TDD, try it on everything, for several weeks. Keep notes about what’s awesome, and what isn’t. Where it adds value, continue to use it. Where it doesn’t, abandon it. Experiment and refine your understanding of how and why it’s awesome. Eventually, it’ll become second nature to know when to pull TDD out of your tool-belt.
Rather than declare “TDD is Dead”, I’d like to see a discussion about how we can put an end to prescription in software development. It runs rampant and jeopardizes the value of too many amazing practices by neglecting to convey the principles behind them. How can we shift the focus back to creating value for our customers, independent of the practices we employ?