software solutions / project leadership / agile coaching and training

The business value of test-driven development

Posted on January 25, 2010

Most businesses are creating software for one primary reason — to make money. In order to make money, we need software that meets the needs of the business and can be developed and maintained in a reasonable amount of time with a high level of quality. Test-driven development is a discipline that will help you achieve these goals.

Test-driven development involves writing automated unit tests to prove that code is working. The test code is written before the implementation code is written. By writing the tests first, you will know when the code is working once the tests pass. Test names are written as sentences in plain English so that the tests describe what the code is supposed to do. Over time, you will end up with a large suite of automated tests which you can run in a short amount of time. These tests will prove to you that your code is working and will continue to work as you modify or refactor the code base.

Most software applications are intended to be used for many years, and throughout most of their existence, someone will be changing them. The total cost of ownership of an application goes far beyond the cost of the initial effort to create the initial version of the software. The first release is the easy part — you can build the application from the ground up, you don’t have many hindrances, and developers feel very productive. But as time goes on, productivity tends to decrease due to complexity, developer turnover, poor software design, and any number of other reasons. This is where software development really becomes expensive. So much focus is placed on the original cost of building an application without considering how the original development effort will affect the cost of maintaining that application over several years.

Test-driven development can reduce the total cost of ownership of an application. New developers on the team will be able to change the code without fear of breaking something important. The application will have fewer defects (and far fewer major defects), reducing the need for manual QA testing. Your code will be self-documenting because the tests will describe the intended behavior of the code. All of this leads to flexible, maintainable software that can be changed in less time with higher quality.

Software is intended to deliver business value, and test-driven development will help you write higher quality, more maintainable software that can be changed at the fast pace of the business. Test-driven development will lead to successful software projects and enable you to write software that will withstand the test of time.


  1. This is 100% true but there’s an interesting corollary. Contractors that don’t retain code-ownership would tend to find the least use out of TDD. Unfortunately these sort of software shops tend to drive our industry. So then what’s the business value for them to implement TDD practices?

    George Mauer — January 25, 2010 @ 12:23 pm

  2. @George,

    As a consultant myself, I have to take pride in my work and be disciplined enough to not create a mess for other people to deal with. That’s not something that I want attached to my reputation. :)

    TDD helps me quite a bit while I’m developing the application — there is plenty of short term benefit to it. I still need to know that my code is working and that I’m not going to break things.

    Jon Kruger — January 25, 2010 @ 12:28 pm

  3. The business value of test-driven development…

    You’ve been kicked (a good thing) – Trackback from… — January 25, 2010 @ 12:28 pm

  4. [...] This post was mentioned on Twitter by Mark Nijhof and Jon Kruger, Alf Kåre Lefdal. Alf Kåre Lefdal said: RT @MarkNijhof: RT @JonKruger: Blogged: The business value of test-driven development [...]

    Tweets that mention Jon Kruger’s Blog » The business value of test-driven development -- — January 26, 2010 @ 12:04 am

  5. The benefits you list also come without TDD …

    They are provided also by … BDD, POUT, Automated Integration testing and by a good QA department and process

    The benefits of TDD are little to do with long term maintenance, but to do with driving out a design in code. Testing is not the important part of TDD … Design is.

    That said, I could and would argue that TDD is not a great way of driving out a design for most scenarios, and BDD or even just spiking, would provide a faster and leaner solution, and more long term value

    Jak — January 26, 2010 @ 7:27 pm

  6. Jon, you need the word “malleable” in this post somewhere.

    @George – I’ve done my share of contracting as well, and though the code-ownership is usually short term, you have to have that ownership while you’re writing it because somebody is going to maintain this system after you leave. That somebody could be you at a later date, as well. To operate under the assumption that, “I’m just here a short time, I’ll hack in whatever I need,” is unprofessional.

    @jak, I’d argue that TDD is a strong side of the maintenance of a system. You’ve got a strong suite of tests to maintain against, the “safety net” to know you’re not doing damage elsewhere. The practice of TDD is for design, but the result of it does make maintaining an app much easier.

    Tim — January 28, 2010 @ 10:27 am

Leave a comment

I have over 15 years of software development experience on several different platforms (.NET, Ruby, JavaScript, SQL Server, and more). I recognize that software is expensive, so I'm always trying to find ways to speed up the software development process, but at the same time remembering that high quality is essential to building software that stands the test of time.
I have experience leading and architecting large Agile software projects and coordinating all aspects of a project's lifecycle. Whether you're looking for technical expertise or someone to lead all aspects of an Agile project, I have proven experience from multiple projects in different environments that can help make your project a success.
Every team and every situation is different, and I believe that processes and tools should be applied with common sense. I've spent the last 10+ years working on projects using Agile and Lean concepts in many different environments, both in leadership roles and as a practitioner doing the work. I can help you develop a process that works best in your organization, not just apply a prescriptive process.
Have any questions? Contact me for more information.
From Stir Trek 2017
Iteration Management - Your Key to Predictable Delivery
From Stir Trek 2016 and QA or the Highway 2015
From CodeMash 2016, QA or the Highway 2014, Stir Trek 2012
The Business of You: 10 Steps For Running Your Career Like a Business
From CodeMash 2015, Stir Trek 2014, CONDG 2012
From Stir Trek 2013, DogFoodCon 2013
(presented with Brandon Childers, Chris Hoover, Laurel Odronic, and Lan Bloch from IGS Energy) from Path to Agility 2012
From CodeMash 2012 and 2013
(presented with Paul Bahler and Kevin Chivington from IGS Energy)
From CodeMash 2011
An idea of how to make JavaScript testable, presented at Stir Trek 2011. The world of JavaScript frameworks has changed greatly since then, but I still agree with the concepts.
A description of how test-driven development works along with some hands-on examples.
From CodeMash 2010
From CodeMash 2010