About
Exploring Solution Spaces, Keith Ray's blog on Software development and other topics.
Send comments to:
keithray@mac.com
| For Agile Training, eLearning, or Coaching contact: |
| Industrial Logic, Inc. |
| 866-540-8336 (toll free) |
| 510-540-8336 (Berkeley, California) |
| Links |
| xpminifaq |
| Résumé |
| “Adopting XP” Article 2002 (pdf) |
| “ Refactoring” Article 2006 |
| AYE Conference |
| Lucien W. Dupont |
| Elisabeth Hendrickson |
| Johanna Rothman's Managing Product Development |
| Brian Marick's Exploration Through Example |
| Esther Derby's Insights You Can Use |
| Laurent Bossavit's Incipient(thoughts) |
| Dale Emery's Conversations with Dale |
| Martin Fowler's Bliki |
| Creating Passionate Users |
Archives
Subscribe
RSS Exploring Solution Spaces XML
2003.Dec.20 Sat
Christian Sepulveda observed the following:
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.
4 minutes compiling and debugging * 8 times/hour = 32 minutes/hour. Imaging how much worse this is in C/C++ environments where just compiling and linking costs 5 minutes or more before getting into the debugger.
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 correct 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.
[...]Faced with such results, the team in my example did adopt TDD. Their feedback loop was reduced to thirty seconds. [...] The same team could theoretically accomplish the same work in one hour each day instead of eight hours. [...]
[...] I have observed, with the specific team, that it isn't quite 8x acceleration, but it is greater than 2. Isn't twice the speed worth the effort to learn TDD?
Add in pair programming, which provides instant code review, finding those problems which are obvious to a person who didn't write the buggy piece of code, and XP-style development really rocks! The pair partner helps you find problems before you run your code, (or helps you diagnose why a test didn't perform as expected), so again you spend less time in the debugger.