The post I wrote comparing TDD to a cargo cult heated a bit of discussion, both in the post comments and on reddit.
I will admit that I probably did not make the case that TDD was a cargo cult, though that title succeeded in grabbing attention. Scott Saad better addressed the cargo cult aspect of it in his post on programming with purpose. My focus, shifted instead to the problems I had when trying to use TDD. The reaction was clearly mixed. Some agreed with some of my points, and others vehemently disagreed.
My discussion of code coverage made a few feel that I was building a straw man to tear down. While I didn't intend to go on a tangent, I am not the first to try to connect TDD and code coverage zealotry.
I think another problem with my post was that I didn't define what TDD is. I recently ran across this post from Roy Osherove that lists 4 different possible meanings:
- Test Driven Development - Writing Code in a Test first manner when you already have a design
- Test Oriented Development - Having lots of integration and unit tests, but necessarily writing them first.
- Test Driven Design - Driving Design completely from the tests
- Test Driven Design and Development - Using TDD to drive new code and changes, but having a design already in place.
The focus of my previous post was really on my problems with Test Driven Design, that is driving your design from tests alone.
I can, however, see where Test Driven Design and Development can have real value when added to a well thought out existing design. This approach reminds me of how the Larry David HBO sitcom "Curb your Enthusiasm" is produced. For those who are not familiar, the show eschews "traditional scripts in favor of detailed scene outlines from which actors improvise dialogue." The resulting episodes are actually very funny in large part due to the very talented actors working on the show. I can probably imagine it not going as well if the actors didn't have the instincts that they do.
To bring the analogy back to building software, if you create a detailed outline that describes the design of the software and couple it with a talented team that really knows what they are doing, they can not only pull off the TDD approach, but pull it off brilliantly.
On the other end of it, I can also imagine the consequences of not fulfilling either of those requirements. If you don't give any outline at all and just throw a bunch of actors together, they'll create something, but it would be very hard to predict how it would turn out. And if you try to pull it off without the necessary talent, you risk not only failing, but failing big.
Thinking about these things keep leading me to two questions about pure Test Driven Design:
- What is the role of an Architect when practicing pure Test Driven Design?
- How do team members collaborate if they are both using Test Driven Design and are dependent on each others work streams? (The classic deadlock problem)
Searching Google didn't seem very helpful, but maybe I haven't chosen the right keywords.
Let me know what you think.
