Why are Test Drive Development (TDD) practices so often considered a waste of money?

As an Agile champion (self proclaimed) I have been banging on about the benefits of TDD for a number of years. Never really from a developer angle, more from the PM and management point of view, yet only the developers ever seem to listen.

Perhaps I have never really had the best arguments to win people over and management have been stuck in the test last point of view. I decided to write this post given some recent experiences on a project that went live with zero defects (doubtless there are some still to be found), with more scope than the original contract specified and 10% under budget. Sounds like a good argument to win people over to me.

This is not a boast about the team’s prowess or my coaching contributions – just the facts. These facts were brought about in part by:

• Great teamwork
• Good architecture
• Clear product vision
• An effective product owner
• Well understood Agile practices and beliefs

However in this case the steady pragmatic application of test first practices and tools (such as Cucumber and Rspec) made a big difference.

We developed the product (a web based transport management tool for a logistics company) in about 500 hours and about 100,000 lines of code, again nothing special. What was great was that we found 66 bugs throughout the entire four-iteration project and of those only seven were found by the customer.

Why do I think that writing our test first made a significant difference? Here’s an example of where it helped: halfway through the project the product owner changed the product in a way that forced us to change and re-factor a significant amount of of the previous work. However as we could run the tests after every code commit it was so easy to see where code developed earlier was impacted and needed rework. In the end we had two regression bugs that our automated tests did not find – the rest were picked up during development. For this fact alone writing our tests first saved us (and our customer) a significant amount of time and money. I shudder to think what things would have been like should we have done the testing manually and after development.

The project was not resourced full time either. This meant that team members might not do anything on the project for a couple of days. The necessary warm up time to remember where you were in the project is reduced as you can write the tests for the scope you need there and then and get straight into development.

We also included automated checking for valid HTML. This was something we hadn’t done before with automated testing and it made it much harder to accidentally commit broken HTML without noticing. It also made it easier for developers without much experience writing semantic HTML to do so and overall helped keep our commitment to good HTML.

For those of you driven by more by financial gain than engineering practices look at it this way:

Less bug fixing = more time spent on chargable work.

Happier customers (from fewer spec errors etc) = more follow up work (that’s free marketing).

Development teams understanding the project quicker = faster time to market = happier customer, more follow up work and ultimately more money in the bank.

So the next time you start a project and say no to TDD think about all of the advantages to your organisation you are leaving behind. And if you haven’t tried TDD before reading this post, give it a go and thank me later.

Mike Lowery is an Agile Consultant and Scrum Master at 3months.