Jeff's Blog

Musings about software development, Java, OO, agile, life, whatever.


Wednesday, January 20, 2010 
Tradeoffs

This graph, intended to show the differences in outcome between TDD and not, is a sketch of my observations combined with information extrapolated from other people's anecdotes. One datapoint is backed by third party research: Studies show that it takes about 15% longer to produce an initial solution using TDD. Hence I show in the graph the increased amount of time under TDD to get to "done."

The tradeoff mentioned in the title is that TDD takes a little longer to get to "done" than code 'n' fix. It requires incremental creation of code that is sometimes replaced with incrementally better solutions, a process that often results in a smaller overall amount of code.

When doing TDD, the time spent to go from "done" to "done done" is minimal. When doing code 'n' fix, this time is an unknown. If you're a perfect coder, it is zero time! With some sadness, I must report that I've never encountered any perfect coders, and I know that I'm not one. Instead, my experience has shown that it almost always takes longer for the code 'n' fixers to get to "done done" than what they optimistically predict.

You'll note that I've depicted the overall amount of code in both graphs to be about the same. In a couple cases now, I've seen a team take a TDD mentality, apply legacy test-after techniques, and subsequently refactor a moderate-sized system. In both cases they drove the amount of production code down to less than half the original size, while at the same time regularly adding functionality. But test code is usually as large, if not a bit larger, than the production code. In both of these "legacy salvage" cases, the total amount of code ended up being more or less a wash. Of course, TDD provides a large bonus--it produces tests that verify, document, and allow further refactoring.

Again, this graph is just a rough representation of what I've observed. A research study might be useful for those people who insist on them.

Labels: , ,


Comments:
Sorry, Jeff, but I don't believe it and cannot find any corroboration for your contention that the time from done to done-done is "minimal." The time from done to done-done is shorter with TDD, but only on trivial projects is it as short as you indicate. On large projects, functional tests---not generally a part of TDD---often reveal important gaps and other problems that require more than a sprint's worth of time to fix.
 
Good thought. The projects I've been on where this time was so short were where the iterations were also short--not 30 day sprints, but one and sometimes two-week iterations.

This isn't the norm (most places require all that test-after time you speak of to run more robust tests), but these were places that were using a heavy amount of automated tests to verify things. Coupled with very short iterations, this allowed the teams to release software with high confidence, knowing that the things they would find (likely to be low severity) in production could quickly be rectified. Rare but it does exist.

The key point is that when you do get to the test-after period (i.e. the time between done and done done) after having done TDD, you do find far fewer problems to have to fix. In an environment where you have not been doing TDD, the defects that arise can easily cost many times more than in a TDD environment.

Maybe "minimal" is not a good word. Substitute "reduced."
 
Post a Comment

Links to this post:

Create a Link



<< Home

RSS Feed (XML)

Archives

February 2004   March 2004   May 2004   September 2004   October 2004   January 2005   February 2005   September 2005   October 2005   November 2005   December 2005   January 2006   February 2006   March 2006   June 2006   August 2006   January 2007   February 2007   March 2007   April 2007   September 2007   October 2007   November 2007   December 2007   January 2008   February 2008   March 2008   April 2008   May 2008   June 2008   July 2008   August 2008   September 2008   October 2008   November 2008   December 2008   January 2009   February 2009   March 2009   April 2009   June 2009   August 2009   December 2009   January 2010  

This page is powered by Blogger. Isn't yours?