One concept that I heard frequently at Agile 2005 was Technical Debt (see definition). Ward Cunningham apparently originated this metaphor and I think it’s a helpful way to think about some of the things that happen in day to day development efforts.
You incur technical debt when you put off doing something in your development efforts. Debt might include a bug backlog, not refactoring code when it needs it, leaving compiler or FxCop warnings in your product code, not doing a thorough job of writing unit tests, skipping a code review, or taking some other short cut in order to meet a milestone.
As Martin Fowler explains in his post on the topic, putting yourself into technical debt may be the right business decision in the short term. But with any debt, you have to pay interest on the debt. If you get too much debt, you lose control and ultimately go bankrupt. Keeping your debt under control is a good idea both financially and technically.
Agile approaches place a strong focus on technical debt avoidance. The practices of unit testing, refactoring, pair programming, continuous integration, and others help ensure that the code base has high quality and low debt.
Keeping your technical debt low is an ongoing challenge given strong feature demands and fixed schedules. It’s critical that your Product Owner / Customer understands the long term payback for low technical debt so that they can help make the trade-offs required to ship a high quality product. Having exit criteria with items related to code quality is one good way. In MBF, we need to consider compiler warnings, threat modeling, FxCop warnings, code coverage, and reduced overall bug count from the previous milestone when we exit the current milestone. There’s a lot to think about, but it’s the right thing to do in the long haul.
Pay me now, or pay me more later.