Jeff's Blog
Musings about software development, Java, OO, agile, life, whatever.
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: TAD, TDD, test-driven development
: 5/08/2010 01:04:00 AM
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."
Links to this post:
<< Home
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
