Pay Your Debts

Debt, when well-managed, is a useful financial instrument for both ordinary citizens and successful organizations. It balances present insufficiencies by borrowing against future surpluses. Used judiciously, short-term debt is an effective tool for smoothing out the rough edges of cash ebbs and flows. When abused, it becomes a burdensome yoke that makes it increasingly stressful to move along.

In the world of software development, borrowing time can be a useful strategy for meeting “at risk” milestones, while completing most of what needs to be done. Ward Cunningham introduced the notion of "technical debt" as something developers can incur as they head toward the end of an iteration,* or a deadline, if time gets short. At that point, they may not be able to do code right, but by taking some shortcuts they may be able to program code "right enough" to still cross the finish line.

Even though the software is in a temporary, imperfect state, this is a perfectly reasonable thing to do if the technical debt incurred is managed responsibly. If it is not paid off, however, it will start to become more painful to do over time. Continued borrowing against the future without repayment will put the project further at risk.

The best way to pay off your technical debt is to assess what "loans" were taken at the end of each iteration. Ask your developers to identify specific hacks** they would like to unwind, and quantify how much time they think they need to do so. They do not need to pay debt off immediately, but it is good to gauge the extent of the needed repair while the shortcuts are still fresh in the developer's minds.

Make sure there are specific code problems identified to be rewritten, not just arbitrary buckets of time requested. This is not an opportunity to goof off, it is a disciplined approach to keeping your code base clean.

Additionally, an increasing array of software analysis tools such code coverage, coupling analysis, and detection of style deviations can automatically help identify places where debt has been incurred, perhaps without your knowledge. Enter these items into your issue tracking system and schedule them against future iterations. By balancing the workload to include new business functionality and paying off loans, it possible to keep your technical debt from spiraling out of control while still satisfying customer feature requests.

Software gets unwieldy for many reasons. But it usually comes down to hacks, insufficient documentation, inappropriate dependencies, shortcuts, and deviations from the intended design. When developers throw up their hands and say they need to start over on a system, chances are unpaid technical debt has become overwhelming. They feel the need to declare the software equivalent of bankruptcy.

By identifying this debt along the way and dealing with it quickly, you can make more frequent "minimum payments" to prevent ensuing chaos. This metaphor is a surprisingly useful way to explain to business stakeholders how software can become unmanageable over time and why they should invest in keeping code clean.

• Iteration - A short period of time chosen by an Agile project team (week, 2 weeks, month, etc.) during which a key requirement chosen by the customer will be developed, tested, and then delivered to the customer for approval or comment. The next iteration will then begin to develop the next most important requirement and/or correct the work done in the preceding iteration.
• Hack - A quick fix or solution to a programming problem, which works but is less than ideal and may need to be revised when time allows. Fixing the inelegant code may be referred to as “unwinding a hack”.