Value of Test-Driven Development

Some time ago I stumbled upon this paper (http://www.ipd.uni-karlsruhe.de/Tichy/uploads/publikationen/35/edser03.pdf). One of the reasons for me stumbling upon this article was my frustration in fellow developers either religiously for Test-Driven Development or religiously against. Surely there must be some objective truth to be found on TDD? Surely it cannot always be good? And reluctantly I must admit that it cannot always be bad either. Reluctantly. Anyway – The article mentioned above is brilliant and objective, and propose a scientific model to determine under what circumstances TDD deliver return on investment.Because clearly there are some investments associated with Test-Driven development, like the act of writing the tests or changing them to support your current intentions of the code, and some benefits like the life cycle benefit in quality measured by the number of defects that the TDD team finds and fixes, but the conventional project does not.

To many TDD advocates it is not clear that there are any investments at all associated with TDD. But if we revert to the base case of a simple method written correctly by a conventional team and a simple method written correctly by a TDD-team we see that the TDD-team have to do more work by definition (in the coding phase). Return on investment can materialize in all other cases and phases of the project but in the base case above will not (since the method was without error). I believe that no one successfully can defend the position that a conventional project is always unable to implement methods that are free of defects, or the fact that all conventional projects will always use more time in the testing phase then TDD projects – just image the lazy conventional project that simply trust in the code written and accidently or by skill gets it correct in the build phase. More importantly – we are currently not to my knowledge applying any discount to the Systems or Acceptance Test phases of our projects, depending on the practice of using TDD or not. And we are certainly not doing so using a scientifically justified method (Or maybe we are, by accident or skill… I simply can’t tell).

I can also easily see why, because it is equally clear to me that we sometimes confuse the act of "Writing Unit Tests" with Test-Driven Development as defined in the article above. I believe that few things could be more dangerous to projects.
To be honest we shouldn’t be very surprised or disgruntled by the fact that the developer community hasn't settled the debate once and for all, or that we haven’t found the magic multiplier for time saved or lost if using TDD or not. After all, science reveals that such factors depend on the project team. And I couldn’t be less surprised.​