The article appears to assume what it is asserting about TDD (Test Driven Development):<p>Of course, this is a fictional example making a lot of assumptions. Your mileage will vary based on lots of factors, including your team’s experience with TDD, the presence or absence of other quality measures (such as code review), etc…<p>Here are the assumptions made:<p><pre><code> Production bugs without TDD: 100
Production bugs with TDD: 40 (60% fewer, middle ground between 40% — 80%)
Average time to fix bug at implementation (TDD) phase: 1 hour (this number is only used to derive the production bug fix cost)
Average time to fix a production bug: ~15 hours
</code></pre>
The author does try to justify this by saying:<p>The relative results of this fictional example ring true to me based on my experience with real production projects, both with and without TDD.<p>BUT...<p>Where is the specific data and how representative is the author's experience of all or most software development?<p>Software development is enormously varied. Kent Beck initially hawked TDD based on a project to rewrite Chrysler's payroll system that was cancelled.<p><a href="https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System" rel="nofollow">https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compens...</a><p>Also see:<p><a href="https://stackoverflow.com/questions/10149798/how-tdd-is-related-to-extreme-programming" rel="nofollow">https://stackoverflow.com/questions/10149798/how-tdd-is-rela...</a><p>The Chrysler C3 project is not the most convincing argument for TDD or other of Beck's ideas. But even assuming the C3 project was a roaring success -- a highly debatable proposition, one should ask how applicable the results are to many other quite different types of software projects.<p>Similarly, what is the author of this article's actual experience and how applicable is it to other types of software projects?<p>I don't question that automated tests can be helpful and indeed critical in some projects but I do question rigid orthodoxies like TDD or requiring unit tests for every function or class after implementation (many people promote unit tests everywhere while claiming they are not doing TDD).<p>Tests take additional time to design and implement and thus cost more. They also have maintenance costs. Architectural and other changes in the software as it is developed can and do result in revising or rewriting the tests as well.<p>Many successful software projects were designed and implemented in the 1970's, 1980's, 1990's, and even today without TDD and without unit tests -- or code reviews although I am focusing here on TDD and unit tests.