Information dissonance and TDD

A colleague from Italy asked me for my opinion about this piece from TechCrunch, You’ve Got To Admit It’s Getting Better. This is a post related to the now infamous rant from Ryan Dahl of Node.js fame about the status of software in general, and how different layers of code and components integrate in particular. Rather than an harmonious dance of well balanced and fine tuned libraries, Dahl is right to point out that quite often we work with layers and layers of complexity and leaky abstractions which end to expose, most of all, an annoying dissonant impedance mismatch. While I partly agree with Dahl, I have to admit that also Jon Evans of TechCrunch has a valid point: it’s getting better, not enough probably, but better.

What has caught my attention more is something else though. I’m pretty sure that my friend asked me about this because of some unkind words for TDD. So let me get the record straight:

  • First of all, it’s just wrong to say that TDD is “the notion that a development team’s automated tests are even more important than the actual software they write, and should be written first” (Jon Evans himself) => no TDD practitioner in his right mind would describe TDD in that way. In particular, nobody would consider the tests more important than the actual software. So, yes, we TDDers think that testing is important, because for us testing is first of all a design technique and tests are a nice byproduct of this technique, one that allows you to evolve your code without breaking existing behaviour in an uncontrolled way. But none of us would try to say that tests are more important, please! If you write about something that is clearly not your forte, at the very least you should not make such a gross mistake.
  • I don’t know where I’ve lived in the last 10 years, but TDD has never “seemed almost sacrosanct” (Jon Evans again). I’d argue that still only a minority of developers actually test their code in these days. TDD practitioners then are a minority of a minority. So, please, spare me the drama about the industry changing its mind about TDD.
  • With regards to the two linked posts, I have to confess that I have no idea who are the authors. That doesn’t necessarily mean anything per se, just that I don’t have any prejudice about the authors. I’ve never read anything from them before.
    • Pieter Hintjens seems to recommend that rather than testing your code, you should throw it out in the open and have people (users) testing it for you. It seems that his main argument is that, even if you think you know how to test your code, you don’t know if your code is valid in the hands of users. Apart from the fact that it doesn’t seem a very professional approach, this is mostly nonsense to me: testing and validation are two different things. Sure, you need your software to do something useful for your users, otherwise it can be correct but it would be of no purpose at all. So, assuming that your software solves the right problem, how do you know that it solves it correctly? Testing to the rescue. In the end the author even admits that he uses TDD for his APIs…
      Having said that, remember that TDD is first of all about design and evolution. So I think that this point is totally wrong.
    • Peter Sargeant rants about dogmas and Agile Testing Experts recommending to always write your tests first. The term “Agile Testing Expert” is funny enough already: there are no such people, there is no agile testing, thank God at least there is one aspect of XP that the Agile crowd has not been able to jeopardize with their brand (oh, they tried, but they also failed miserably – some people cover TDD, BDD, ATDD and other practices together under the umbrella of Agile Testing, but it seems quite fictitious to me and it has never been accepted in the community in that way). So, if you talk about Agile Testing Experts I’m already suspicious. Once again, this post seems to miss the point of TDD: it’s about design and evolution, testing is a collateral, an important one but still a collateral. Do I always write my code following TDD? No, I don’t. I rarely use TDD if I’m spiking or prototyping. I never use TDD for one off pieces of code that won’t survive to see the light of a new day. I very rarely use TDD for pure UI code, especially when it’s about HTML and views and layout and CSS… (you get what I mean I guess). And I never use TDD when I don’t know what I’m doing, when I’m exploring.
      Anyway, Peter Sargeant’s blog is in the end about promoting testing automation, so his rant is more about breaking away from dogmas and using your head to judge when to use a tool, so it doesn’t seem to me to be such a big deal.

In conclusion, yes, things may get a little better and no, I don’t think that there is a whole movement against mainstreamed (!!) TDD in the software industry.


Tags: ,

5 Responses to “Information dissonance and TDD”

  1. Shmoo Says:

    TDD is fine when you can delay your product releases to accomodate the (at least) 16% time-penalty that all studies of TDD show it involves.

    When you can’t delay that 16%, you have to drop TDD.

    • thinkingbox Says:


      none of the studies that you mention should be considered conclusive for the assertion that “TDD implies more effort”. Certainly not the ones conducted by Laurie Williams in 2003, nor the most recent ones by Nagappan et al. In fact, none of the authors of those studies try to generalize the result: they just observe and report the differences in the various teams. They certainly don’t match my experience working with different teams in Europe and Canada.
      I should write a post about those studies, one day or another.

    • xpmatteo Says:

      If you don’t care too much about if it really works you can save much more than 16%!!

    • Ted M. Young (@jitterted) Says:

      +1 on what @xpmatteo says…

      Even if it were true that in all cases doing TDD caused an increase in time to complete, for most code bases the overall cost is not in the initial development, but in the maintenance done over years (or even decades). If TDD results in lower ongoing costs, then it’s well worth it. Studies of TDD (e.g., that show smaller (in some cases drastically smaller) code bases imply lower maintenance costs and higher quality (many studies have correlated lines-of-code with bug counts).

      However, my experience has been that TDD results in higher productivity for non-trivial requirements.

  2. BraveNewCurrency Says:

    Let’s say there is a 16% penalty in time releasing version 1. When it comes time to release version 2, how long will you have to test it to make sure there aren’t any regressions? And version 3?

    Yes, TDD is more work, but at the end you get a completely different product: one that quickly detects when a someone has a brain fart and breaks something that used to work. One that comes with a little user manual that tells you how to call each function and what to expect.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: