Steve Freeman

So, by one reading of Roy’s posting, I appear to have become the reactionary voice of TDD, a sort of technical William F. Buckley, which is not something I aspire to.

The question is how to get all those developers to do TDD when, apparently, they don’t know the basics of software design. It seems the answer is to separate the two, to teach unit testing while ignoring the issue of code quality in the expectation that people will catch up in the end. I absolutely agree that it’s important not to overload students, especially after reading this paper¹, but this solution doesn’t make sense to me.

My experience is that unit testing ill-structured code is an adventure in software callisthenics, requiring feats of special deviousness; Michael Feathers wrote a whole book about how to do it. Tools that slice through the runtime may sometimes be necessary, but dangerous power tools should only be used by trained staff². This is fixing the wrong problem.

My suggestion is to start by improving the design skills of your team, that’s your biggest problem. There’s so much material available, all well-established; for example, you could buy a copy of Object Design and some index cards. There’s a catch, of course, in that this is not a shiny new technique so funding for actually training staff is harder to justify, but you know how to work around that.

In the meantime, write an automated build and some acceptance tests around the system—not for everything, but just enough to show that the application will do the basics when you start it up. For many teams, this would be a significant advance. When this has bedded in and the the team has begun to write objects that tell each other what to do, it will be time to move to a higher astral plane (my shamanic rates are quite reasonable) and start the first stumbling steps in TDD.

The alternative is to do TDD without understanding and, from what I’ve seen, that ends up with exactly what some people complain about, twice as much code for no benefit. My guess is that a brittle, incomprehensible tests suite will not survive the first deadline crisis.

The irony of all this is that, despite my apparently being part of a consultants’ cabal that is protecting its elitist interests³, this approach is likely to be cheaper since material on good OO design is a commodity nowadays and deferring the adoption of full-scale TDD will be less disruptive.

1. via Mark Guzdial’s excellent blog
2. I love this quotation from the article: And the number one most dangerous power tool in your wood shop is YOU.
3. Is this where I turn into Obama?