the death of tdd

Several years ago, Colin had the pleasure of working with Mike and his team as they embarked on their Agile journey. As with many teams, they went through stages of what might be termed maturity. First, they learned how to plan and work iteratively, later they learned incremental working. Finally, they reached a point where they wanted to improve their engineering practices and so Colin had introduced them to Test-Driven Development. Now he was sitting listening to Mike, the technical team lead for the team, explain to him why TDD wasn’t working for them.

"You see, TDD forces you to decouple everything” he said, “You taught us the SOLID principles, JSP and the Composed Method pattern?” He looked down into his cappuccino, “you introduced us to clean code, too. We’ve followed the rules in the book to the letter and now we’ve found it’s just too difficult to write code.”

I was curious about his statement, “What do you mean it’s too difficult?” I asked.

Mike was hesitant at first but eventually started to open up, “TDD forced us to produce a disintegrated codebase that is too decoupled. It makes it difficult to follow the flow of logic through it. We call it test-induced damage, caused by us sticking to the rules. Producing even the smallest piece of functionality seems to take an age now and has become a bit of a chore.”

Taking a moment to consider, Colin asked him, “Do you remember the seven deadly sins of design? Do you remember the deadliest sin?”

Mike looked at him in puzzlement, “Of course, not doing any is the biggest sin but we’ve been doing design as per the principles you taught us and it’s just not working.”

Colin explained, “You followed all my advice except for the most important piece: the principles are not rules; they are guidelines. TDD cannot and does not make design decisions, only people can do that. You and your team made the design decisions that produced your fractured codebase, not TDD.”

Mike considered this for a moment before responding, “I think you’re right, we’re all looking for a simple rule to follow and if following that rule leads to problems, we blame the rule, not the fact that we followed it blindly.”

“You’re not actually doing design!” Colin went on, “The mindless application of a rule, or even set of rules, is not doing design. Design is a mindful activity that requires the awareness of different, sometimes conflicting, drivers and the application of judgement to make appropriate trade-offs between them. It’s your ability to make those judgements and how well you make them that determines your competence as a professional.”

“I feel such an idiot,” said Mike, starting to look a bit sheepish, “I can see it now. We picked up the SOLID principles, used them as a Golden Hammer and saw every design opportunity as a nail.”

He looked Colin in the eye and said, “We’re going to stick with TDD but, in future, I’m going to make sure the team is more mindful, is aware of the decision making aspect of design and takes ownership of their decisions.”

“Mindfulness is what it’s all about,” said Colin. ”It’s underlies everything we try to teach. The principles and practices are there simply to make you think about what you’re doing and why you’re doing it.”

After making sure Mike would keep him updated about progress, Colin left the room and as he walked away, he heard a line from Paul Simon’s song, The Boxer, going round and round in his head, “A man hears what he wants to hear and disregards the rest.”