This is a revised posting. I got a little carried away with my math in the example. Sorry.

I was working with a team that had been gradually adopting agile practices, but the developers were resistant to practicing Test Driven Development. At one point, I decided to start tracking how much time was spent compiling code, running the application/debugger, re-establishing the context in the application, observing a result and then closing the application. The developer would think about what he observed, make code edits, start the debugger and repeat the cycle. I observed that it took four minutes on average to run the cycle of compile, launch debugger, find context, etc. This would be done an average of eight times per hour; the remaining hour was spent thinking and making edits.

One half of each day was completely wasted. The developer couldn't really doing anything productive during the four-minute debug cycle because he had to navigate to the corect place in the application and execute the right steps so he could observe the results of the change he just made; he was forced into tedium. In other words, half the development budget was being spent on performing repeated, monotonous tasks. This isn't a very effective use of resources or talent.

The development world has been doing this for years. My analysis may seem a bit naive; the lost time I refer to has been considered a necessary overhead in order to receive feedback. The feedback is necessary but this method of getting feedback is not.

Consider the use of TDD. The same developer makes a code edit, runs an automated test suite and in seconds gets feedback of the impact of his change. Besides knowing the expected impact, the developer knows the impact of his change on the system as a whole, performing a validation of his expectation and regression check in one step. (My analysis of the four-minute debug feedback cycle didn't address the time spent determing the system impact of code changes).

Faced with such results, the team in my example did adopt TDD. Their feedback loop was reduced to thirty seconds. In the example, there were eight edit cycles per hour. Previously, thirty two minutes were being used to get feedbak regarding an edit, so twenty eight minutes were being used to make the actual change, consider options, checkin code, etc. This is roughly three and half minutes per edit, for eight edits per hour.

So now, an edit cycle costs a total of four minutes, which doubles the number of edit opportunites. The greater the number of opportunities you have to introduce edits, the faster your progress. This, in my opinion, is one of the reasons teams using TDD go faster. They get similar feedback they would have received in a debug cycle, but it is compressed so much that it empowers the team. The team has so many opportunities to try something, they can afford to experiment with design changes, clean up code or simply move forward. Not only will the team go faster, but the resulting code is generally more flexible, resusable and readable. (I haven't enough discussed the benefits of regression testing and its related cost savings.)

So the when faced with people resistant to TDD, maybe the question isn't why to use TDD, but how can you afford not to?