To TDD or not to TDD? That is not the question.

Over the past few days a TDD debate has been raging (again) in the blog-o-sphere and on Twitter. A lot of big names have been making bold statements and setting out arguments, of both the carefully constructed and the rhetorically inflammatory variety. I’m not going to revisit those arguments – go read the relevant posts, which I have collected in a handy timeline at the end of this post.

Everyone is right

Instead of joining in the argument, I want to consider a conciliatory post by Cory House entitled “The TDD Divide: Everyone is right.” He proposes an explanation for these diametrically opposed views, based upon where you are in the software development eco-system:

Software “coaches” like Uncle Bob believe strongly in TDD and software craftsmanship because that’s their business. Software salespeople like Joel Spolsky, Jeff Atwood, and DHH believe in pragmatism and “good enough” because their goal isn’t perfection. It’s profit.

This is a helpful observation to make. We work in different contexts and these affect our behaviour and colour our perceptions. But I don’t believe this is the root cause of the disagreement. So what is?

How skilled are you?

In Japanese martial arts they follow an age old tradition known as Shu Ha Ri, which is a concept that describes the stages of learning to mastery. This roughly translates as “first learn, then detach, and finally transcend.” (I don’t want to overload you with Japanese philosophy, but if you are interested, please take a look at Endo Shihan’s short explanation)

This approach has been confirmed, and expanded on, in modern times by research conducted by Stuart and Hubert Dreyfus, which led to a paper published in 1980. There’s a lot of detail in their paper, but this diagram shows the main thrust of their findings.


For me, the important point is that novices follow rules and “don’t know what they don’t know”. They need to be given unambiguous instructions while they learn what ‘s important.

At the other end of the spectrum, experts use their intuition and metacognition (an awareness and understanding of one’s own thought processes). They often can’t accurately describe how or why they arrived at a particular decision.

Who are they talking to?

When presenting information it’s important to understand who your audience is. Material that’s suitable for novices is often not useful for experts. Material for experts can be dangerous in the hands of novices.


Some of the contributors to the TDD debate do try to indicate who they are writing for, but most don’t. And even when you do say something like “for experts only” you’re leaving it to the reader to decide if they are an expert or not, which is a decision that we are poorly equipped to make. In fact, the Dunning-Kruger effect shows that people who are in the early stages of acquiring a skill frequently overestimate their competence, while those who are very skilled tend to underestimate it.

The internet is an open resource. No matter what sort of health warning you put on your blog posts, they will inevitably be read by people of differing skill levels. And therein lies the problem. The bloggers have an implicit idea of who their audience is – and it might not be you.

The people who warn against TDD  usually come from environments where the team is working at competent level or above and that’s who they are talking to. If you respond to these posts by thinking “Oh cool. This person is saying that I don’t have to do this difficult thing” then you’re probably a novice. Carry on practicing until it becomes easy and then you’ll know why they didn’t find it useful.

Those who promote TDD often work with teams that are less skilled and they have seen the benefits that derive from acquiring these skills. If TDD is something you’ve already become comfortable with, then you’ll know why you’ve chosen not to use it any more and it won’t be “because it was difficult.”

To TDD or not to TDD. That is not the question.

TDD is a technique that has costs and benefits. Whether it is right for you and your colleagues depends on your team’s context – the domain, the skill level, the schedule, the risk. Like any technique, it’s no use if you do it badly. Like any technique, it can neither help nor hinder if you don’t apply it. If you want to get good at TDD you have got to practice it.

You will need to get good at writing robust unit tests that exercise the behaviour not the implementation. You will find yourself getting better at creating designs that are made up of smaller, cohesive, decoupled components. You will have an automated suite of tests that give you fast feedback, the confidence to refactor and protection from regressions. You will have executable documentation that doesn’t rot over time.

If your development process doesn’t deliver these benefits, you’ll have inevitably felt the pain caused by long debugging sessions, unexpected regressions, poorly structured code and stale (or missing) documentation. There will be parts of the codebase where you fear to tread.

You can acquire unit testing and design skills without practicing TDD, but many people find that the structure of TDD really helps keep focus. Once you get good, you’ll be competent (or better) in all these skills and well placed to decide whether the cost of TDD outweighs the benefits or not. The skills you’ve picked up on the way will be invaluable whichever choice you make.

But if you’ve never tried TDD, or you’ve never practiced enough to be comfortable with it, then you’re still a novice. My advice is to keep on practicing – it’ll be worth it.

Selected posts and tweets

September 30, 2008 : Kent Beck –

Unknown date, 2009 : J.B. Rainsberger –

October 6, 2011 : Ian Cooper –

May 1, 2013 : Steve Fenton –

May 13, 2013 : Steve Fenton –

July 15, 2013 : Philip Ledgerwood –

January 13, 2012 : Dan North –

June 12, 2013 : Ian Cooper –

January 25, 2014 : Justin Searls –

January 27, 2014 : Uncle Bob –

February 25, 2014 : Santiago Basulto –

April 23, 2014 : David Heinemeier Hansson –

April 25, 2014 – Uncle Bob –

April 29, 2014 : Kent Beck –

April 29, 2014 : David Heinemeier Hansson –

April 30, 2014 : Gary Bernhardt –

April 30, 2014 : Uncle Bob –

April 30, 2014 : Tom Stuart –

May 1, 2014 : Uncle Bob –

May 1, 2014 : Cory House –



, ,



3 responses to “To TDD or not to TDD? That is not the question.”

  1. Cory Avatar

    Hi Seb – Excellent post. Thanks for the quote! And I really liked your long list of links at the bottom. Showed me a few I haven’t read yet!

  2. Marc LY Avatar
    Marc LY

    Wow, thanks for the links!! and in two words: YOU ARE ABSOLUTELY RIGHT!
    Except maybe when you talk about experts like Uncle BOB. I don’t know him personnaly but when I read him, when I see him (on videos), when I listen to him, I must disagree with you: he is convinced because not only he made it his business but mainly because the “method and the principles” convinced him.
    And again without knowing him personnally nor the other experts, I can say that with TDD, even only at “advanced beginners” level only, can you feel a real ease of development through at least “90%” of your production code… simple codes are simply and fastly tested, so on demand, you can get a “green sign” that always cheers :o) and you can fastly see what when wrong and where when a test fails.
    That ease only can convinced a lot of people.
    Imagine what you can achieve when you have only to focus on 10% of the entire code when you have something to do…
    Imagine what you can achieve when you only have to focus on 1% of the entier code…
    Imagine what you can achieve and how faster you can do it when you can focus only on 10 lines of code!
    ^_^~… that is not the question nor the problem for sure. But if one can be that productive over millions of lines of code, can that one be somehow more productive when he only has to maintain at one specific moment only 10 to 100 lines of code?

  3. […] Does it improve or damage our design? Does it make us faster or slow us down? Seb Rose compiled a list of blog posts and tweets about it, so I won’t repeat them here. If you are not aware of the whole discussions, please read […]

Leave a Reply

Your email address will not be published. Required fields are marked *