October 15, 2010

...Learn TDD with Codemanship

Why I Don't Sell TDD or Refactoring

I'm not really in the business of persuading people to practice Test-driven Development or Refactoring these days.

I've done plenty of that in the past, and I made a conscious decision a couple of years ago to focus on the folk who "get it" and train and coach people who want to be trained and coached whenever possible.

Of course, with corporate clients, there will inevitably be people in the room who are on your course under protest.

Maybe they don't believe in the benefits of TDD. Maybe they probably heard bad things from teams who tried and failed with TDD.

Our aversion to empiricism doesn't help. The few studies that have been conducted in the effects of TDD have drawn conclusions from very small data sets. If TDD was a drug, we wouldn't have gotten it onto the market yet.

sadly, in the eyes of its skeptics and detractors, this lumps TDD in with the likes of homeopathy and acupuncture.

While it's hard to draw conclusions from a handful of projects, the studies seem to almost universally bear out two facts about the effects of TDD:

1. TDD will very probably produce code with significantly less bugs

2. TDD tends not to take longer, except in those case studies where teams were trying it for the first time

The studies done in the last ten years don't examine the long-term effects of these technical practices. We have a theory about what they should be, and we all have our war stories and anecdotes about times when we've seen teams realise these benefits.

We expect that the pace of delivery will be more sustainable, for example. The vast majority of software teams make the mistake of tackling projects like they're 100m sprints, instead of the 26-mile marathons they usually turn out to be. I'm aware of very few teams achieving sustained and continuous delivery who don't apply rigorous technical practices like TDD and refactoring.

I'm very fond of pointing out that what defines the winners in software is not how fast we deliver, but how fast we learn from what we deliver. Even at a very modest pace of delivery, if deployment is frequent and sustained for long enough, the tortoise will tend to eventually outrun the hare.

So the pace the majority of teams should be aiming for is not "fast", but relentless. Like a Cyberdyne Systems T-1000, powered by the Energizer Bunny, the software needs to keep on coming, release after release after release.

Teams that are focused only on their next deadline will probably not see the point of these practices. But even they are misguided, judging by the evidence we do have. I know from experience, and the data bears this out, that we can deliver the same features in the same time, but with fewer bugs and cleaner code. That sounds like a win-win to me.

So, for me and many others, applying TDD and refactoring is a no-brainer. You get better quality at roughly the same cost with each release, and potentially lower costs and shorter lead times over multiple releases.

Learning TDD and refactoring, on the other hand, comes at a cost. The handful of case studies where teams reported lower productivity appear to be teams doing it for the first time, for example. What they're reporting may well be TDD's formidable learning curve. And teams are often unwilling to take that initial hit to climb over the learning curve (which can take many months) to get to the promised land of cleaner, more reliable code and sustainable continuous deployment.

Indeed, I often suspect that when people are vocally skeptical, or even adversarial, about adopting these practices, it's actually this learning curve they're objecting to.

Maybe if we did more and wider studies, we could build a stronger case and many of the skeptics and naysayers would be converted. I suspect not, though. People are not rational a lot of the time. It certainly didn't work for code inspections and defect prevention in the 80's and 90's. There's a mountain of evidence supporting the benefits of inspections. The jury is most definitely not out on their worth. But very few teams applied them.

And back then, just as now, I suspect the reasons had more to do with learning curves and fear of initial pain or discomfort than with the benefits or the data supporting the benefits.

The only effective way I've found to persuade someone of the benefits of TDD or Refactoring is to get them to try it - give it a proper go. It's rare that someone who's really given it a proper airing goes back to working the way they did before. Indeed, many of us can't imagine how we ever delivered working software before - a feeling akin to a stunt pilot learning at the end of an especially risky aerobatics display that he'd forgotten to pack his parachute.

By definition, if they're sat in the room expecting me to train them in TDD, they usually believe in the benefits of TDD and want to give it a go. Not always, but usually. And I firmly believe that people who don't want to learn won't learn. So I make no concessions to the occasional skeptic in the room, because there's little I can do for them. Rather, I ask that they suspend their disbelief for the duration, if only so as not to disrupt the learning experience for the people who are there because they want to learn.

Posted 7 years, 6 months ago on October 15, 2010