Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Sunday, March 20, 2005

Technical Debt: Deficit Spending for Geeks

Technical Debt is the concept that small shortcuts taken over the life of software project accumulate and cause problems down the road (that is, they gather interest).

This implies that technical debt stems from conscious choices made throughout the project with full knowledge of their shortcomings. While this is certainly true, it's only half the story. I think many projects suffer from a more sinister unconscious technical debt.

These mistakes, short-sightedness, and yes, stupidity accumulate over months and years of a software project. This isn't limited to the actual code, its also in the requirements gathering, design, documentation, and the process itself.

I've seen this in diverse areas like:

The Build Process: "Build Script? No, Fred does all of our builds on his machine in Visual Studio. What? Oh, yes, he also develops on that machine. That's funny, yes he DOES keep saying Works On My Machine (TM)"

Configuration: "You have to tweak some settings when you install this software, but I'm not sure which ones - we just ask Joe whenever we need to do it"

Documentation: "It crashes unexpectedly? Oh, you need the latest version of FOOBAR.DLL, that's a well known problem"

Development Process: "We're using Extreme Programming, but we omitted most of the practices so that we just write code as fast as we can. No documentation, no tests, no code reviews, and we don't have any contact with the customer."

Management: "Hiring a QA staff is a waste of money, you developers should just do your own QA, quit being lazy!"

Teamwork: "That's not my problem, its a bug in Joe's module, go talk to him. Oh, you did and he blamed me? Bastard! Well, I can't fix it, it's probably Microsoft's bug"

So how do we solve this problem? Hire smarter people? Hmm...that doesn't work, because even smart people sometimes do stupid things.

The best I've been able to do is to use the Project Post-Mortem - a retrospective on your last development cycle. These are a little bit like cleaning your bathroom, the more frequently you do it, the less it smells in between. A good time to do this is after each iteration or release.

Typical things to cover:

1. What went really well - "Boy, those donuts Sue brought in every day during crunch time really helped me code! Oh, and the unit tests we added caught a lot of problems, too."

2. What didn't go well - "You know, it took me a long time to do integration testing, because the build kept breaking."

3. Suggestions for improvement - "Uh, Fred, maybe you can actually compile your code before checking it in from now on? Maybe even test it?"

4. Obstacles - "My machine is SO slow. If I had another terabyte of RAM, I could be so much more productive!".

5. Explorations - "I just heard about this new supercool utility that can generate our entire codebase with just 10 lines of XML!" No comment.

Your retrospective may vary, but the idea is to get big picture communication on a regular basis. Many teams do a "standup meeting", but its intent is to focus on what's happening today, and rarely covers long-term issues.

So pay down your technical credit card with a project postmortem. You'll be paying off charges you didn't even know you made.

For more agile project planning tools and tips:

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams