Dear ‘Uncle’ Bob Martin,

You compared TDD to hand-washing for surgeons.

But the analogy is skewed because hand-washing was not the innovation at all. The innovation was the Germ model of disease, without which hand-washing advice would have been easy to ignore amidst other claims of the day.

I would think that any claim of TDD superiority must be backed up by being able to point to a single design that could only have come from TDD. This is comparable to validating the germ model by pointing to an infection that could only have come from germs. Is there even a claim that such a design exists, only producible by TDD?

It may be anecdotally wise to TDD in many cases, but there are software success stories from the past using other mindset-driven techniques like Literate Programming. How could you compare two such approaches?

I’ve no problem analyzing tests, and testing practices. But I find the community arguing about the ‘importance’ of test-first TDD to be a real distraction from true, causal analysis of the still-unanswered question, what makes software and its tests robust? I think the SOLID principles – which can be found in code, not just in mindset, are much more solid ground (pun intended!) to build software on than TDD. It comes down to: I think results should be specified, not methods.

Dean Radcliffe