Published: The art of misdirection

I’ve just come back from the excellent NDC 2012 event in Oslo, where they published my article about opportunity cost in The Developer magazine ahead of the conference.

The article is now available on my site. Please let me know what you think about it in the comments below.


  1. Euphoric · ·

    I hope this article is against people who misuse TDD steming from their lack of understanding of thereof. Correct use of TDD (and other agile methodologies) would never cause an isues you are describing. Let me go over the parts you described:
    When should TDD never be used: When you have fixed requirements and you are working in enviroment that you know a lot and never changes. To sum it up: never. There are so few cases where TDD brings more overhead than standard waterfall, that such option is nonexistent.
    Using TDD on short-term projects : Again, correct use of TDD would dictate not doing it. Why? Because many TDD-ers understand, that many TDD practices are only usable on long-term projects. Quickly hacking together some functionality, that will never be changed after completion is quite common.
    Emergent design: What you describe is called Breaktrough in DDD, one of the agile methodologies. Such thing is common in TDD projects. When you know, that your current design is not sufficient, you know that you should rewrite it and re-design it to support new requirements. There is nothing in TDD that forbids this.
    Once you’ve coded it to do that is it ever likely to stop doing it? Yes. This happened many times in the past, and will continue happen in the future. Why? Because there are many people working on code. And those people might not understand full consequences of changes they make. So by changing something, they can brake something completly else. Having automated tests prevents this.
    Conclusion: You only bashed Agile. There is no oportunity cost and trade-offs in what you described. Let me ask you. What are alternatives to Agile? Only thing that is somehow different is waterfall. And it has been proven again and again, that such thing cannot ever work. Yes, there might be downsides to not using TDD(or any agile methodology), but there have yet to be discovered something, that does better than that.

  2. Si Garnett · ·

    The link in the email you sent was broken. Given the article title though…. ;-)

  3. Excellent article. Adopting anything, whether technology or technique, without adequate thought about the costs as well as the benefits, is a recipe for disaster.

  4. Sam Weisen · ·

    Hi, Dan,

    You have, I’m afraid, misunderstood TDD. Let’s take a look at some of
    your accusations.

    “TDD locks in your assumption about the desired end goal.”

    No, in fact, the opposite is true: TDD allows you to move towards
    whatever current goal you would like to aim for right now (as guided
    by requirements, for example) but let’s you quickly change direction
    when you realise that the goal has changed (as when new requirements
    are received).

    “You need an overarching vision, a “big picture” design or
    architecture. TDD won’t give you that.” Wrong. TDD will give you
    precisely that: when you’re working on a large project, TDD allows you
    to build the code in small steps, where each step is the simplest
    thing that can possibly work. The architecture follows immediately
    from that: the architecture is just the accumulation of these small
    steps. The architecture is a product of TDD, not a pre-designed

    “I’ve seen teams burn weeks of development effort creating beautiful
    automated test suites that provided almost no additional assurance or
    feedback over using the application.” Well, that’s not a jab at TDD,
    but if you’ve seen teams do this, then you’ve seen bad teams. It’s
    that simple. Good teams don’t produce loads of tests that bring no
    value. Don’t use bad examples to criticise the most important
    development in design methodology since the punch card.

    “But over time we accumulated many of these “of course not” tests,
    increasing the noise among the signal, so it becomes harder to find
    the really useful living documentation. ” Again, only bad teams do
    this. Good, agile teams don’t. Good, agile teams use TDD to build
    tests that add value, not decrease signal-to-noise.

    Your assault on TDD is vacuous. You probably have some point to make
    in there, but it’s lost in the tirade.

    Must try harder.

  5. “The architecture follows immediately from that: the architecture is just the accumulation of these small steps.”

    To see why that’s a problem, you might want to take a look at the original “emergent architecture”.

  6. […] Software Projects Mature by Accident?”. It even made its way into the comments of the post where Dan North announced that he had reprinted “The Art of Misdirection” on his site. […]

  7. Dan, I love that you continue to speak from experience and challenge us to improve all the time. I’ve heard so many of your stories now about what your team get up to, and seen you talk about their discipline and agility, and I really wish that more teams were like this. Thank you for sharing the blog and challenging us to think beyond the practices that work to those that might work better.

    I can see a few people in these comments who’ve fallen prey to the “No True Scotsman” fallacy; that if something isn’t working for someone, that person must be doing it wrong. It’s a sentiment I’ve seen on a few Agile blogs, too, particularly around TDD but also Scrum. There are so many contexts, from rolling out a timesheet app to fixing an urgent production bug, where TDD simply isn’t appropriate, and many too where TDD is a good practice, but not amongst the best. Thanks for calling our attention to these blind spots.

    I know you’ve got a book in the works, and can’t wait to read it. I’ve been practicing Spike and Stabilize with a lot of teams now and it’s been game-changing, for all that it requires more discipline and expertise than test-first ever did. Please finish it already so we can all benefit!

  8. All those refuting you and saying that you are just “bashing TDD” have apparently fallen victim to the very illusion about which you write. No matter how you slice it, there is no such thing as a “right” methodology. There are many ways to produce good software. In the end, if it makes the end user happy and works well, that is all that matters. All this article is doing is forcing you to go outside of your comfort zone and challenge what you think. I’m sure many successful teams take bits and pieces from all of these methods and put them together to make a productive team.

  9. Maybe we are just getting old;-) Relying on our instincts rather than practices we’ve used before. The team i’m on (of ageing ex-thoughtworkers) are certainly a very different site to what the same group may have looked like five or ten years ago. Less likely to follow any ‘rules’. But is critical thought really the answer to the problem or is it just a sign that we still haven’t nailed it?

    Beautifully written article by the way, even for you. B

  10. Liz, please have the courage of your conviction: if you’re going to call someone out, call them out. Don’t mutter insults under your breath.

    And for the record Dan, Gene and Liz: I think you’re all wrong, and what’s more, your disingenuously misleading the ranks of up-and-coming programmers into wasting their time looking for better design methodologies than TDD when no such beast exists.

    For shame.

    I leave you with a quote from Bob Martin (you probably don’t know who that is), “Anyone who continues to think that TDD slows you down is living in the stone age. Sorry, that’s just the truth. TDD does not slow you down, it speeds you up.”

  11. Sam, I have explicitly mentioned the need for expertise and discipline in the practices that Dan is talking about here. I also mention it in my blog, where I talk about the discipline required to stabilize afterwards:

    TDD is a fantastic practice for the up-and-coming developers you mention. I have found practices which are *even better*. I don’t believe they’re appropriate for any developer who hasn’t experienced great TDD, so it’s still valuable to me. I believe the many posts that I’ve written on TDD / unit-level BDD speak to that already. I’ll let Dan answer for himself.

    I am struggling to see the insults you mention. Please could you give me an example of something you observed as insulting?

    PS: Did you mean this Bob Martin?

  12. ah, Sam…I’d love to say that I admire your fervor and conviction that TDD is the pinnacle of human progress in the design of computer systems. However, I’d be lying. I find that attitude rigid, naive, and cliche. The medieval doctor who clutched posies to his face to ward off the plague was, I’m sure, convinced that that was the culmination of the evolution of medicine. We know how that turned out. When you stop re-evaluating your techniques and how they apply to your situation, your journey to obsolescence begins.

    I do appreciate being put in the company of another accused of corrupting the youth. I’m not vain enough to agree, so don’t bother passing the hemlock.

    For shame.

    Really?? That’s cute.

  13. […] recently blogged on the opportunity costs of our various practices, and used TDD as an example of a practice that carries such a cost. It can take longer to produce […]

  14. Sam Weisen · ·


    That posies-not-warding-off-plague thing?

    Good argument.

  15. […] why the history lesson? Earlier this month, Dan North posted a brief notice that he had just returned from the Norwegian Developers Conference in Oslo and that […]

  16. davehillier · ·

    How ironic, an article pretending to be about lost opportuntity/Cargo Cults, bashing the thing (TDD) you propose an alternative to (BDD).

    For me BDD == TDD.

    1. Hi Dave,

      Thanks for your comments. Funny enough I wrote about BDD == TDD just recently. Not sure I get the irony though, or how the article is pretending to be about lost opportunity: that is what it is about. As I say in the article, there is opportunity cost in every decision. I just used TDD as an example because it’s one of those practises where people say “You have to do it, I refuse to accept there is any other way.”

      For what it’s worth I’m equally critical of cargo cult BDD as I am cargo cult anything else. Liz Keogh wrote a lovely critique of cargo cult BDD last year that you might like.

      1. davehillier · ·

        Ok, a flippant comment, because, I felt that the tone of the article was a bit hyperbolic. In my experience, I have always found that TDD has been beneficial to every project I’ve been on.

        I’ve read your article about BDD == TDD and I think I understand your point of view. I think TDD has a high cost, but it provides very valuable feedback, both that you’ve developing the right thing at that you haven’t caused a regression. I don’t people using different techniques provided they can deliver new features without causing regressions. Not doing anything else is not really an alternative.

        “100% code coverage is an asymptotic goal” and TDD is one of the easiest ways to achieve this.

  17. Oh God yes – question everything, most of all yourself! You picked a hard sell there Dan, demonstrating that TDD might sometimes be inappropriate. Scarcely surprising it’s wound some people up the wrong way!
    Whether people agree with your specific examples or not (and I’m not sure I do), of course TDD isn’t always the best approach. There’s nothing that is always the best approach, and that’s always worth saying. Particularly in the Agile world ;)

  18. […] the new Scrum?”, while Jim Bird asks “What can you get out of Kanban?”. Dan North touched a raw nerve by suggesting that techniques like TDD should be used only when they add value rather than […]

%d bloggers like this: