Technical debt is a metaphor developed by Ward Cunningham as a means of explaining the need for refactoring to non-technical product stakeholders.
In short, the metaphor asserts that releasing a system with suboptimal architecture, design, and/or code burdens the development organization with debt. The interest payments associated with the debt cause future system enhancements to require increased time and effort. If refactoring techniques are not used to pay down the debt, debt can continue to accumulate to the point where enhancement activities grind to a halt, resulting in metaphorical (and potentially literal) bankruptcy.
I believe that this is a wonderfully insightful and useful metaphor. Many others, particularly in the Agile community, find it to be valuable as well, and the metaphor is often cited and explored.
I have been thinking however, about another potentially useful metaphor for conveying this concept—the metaphor of the backpack. I think this metaphor has value because it highlights the idea that the burden incurred by suboptimal development can be evaluated only relative to forward movement or change.
In everyday life, if you incur debt, that debt remains regardless of whether you make any additional future purchases. The backpack metaphor, on the other hand, captures the concept that in software, the burden of suboptimal development can be evaluated only in relationship to forward motion.
Imagine that you have a backpack full of stones. If you’re sitting down, the fact that your backpack is very heavy is of little concern. You’re not moving, so you don’t feel the weight. It’s only when you start walking again that the stones are an impedance.
Similarly, in software development you could take the view that taking shortcuts or making suboptimal design decisions is the metaphorical equivalent of placing stones into your backpack. If you aren’t planning to make any future changes, the stones don’t have much impact. A further complication is that the weight of these metaphorical stones is relative to the route you plan to take (i.e., the future changes you plan to make within your code base). The development shortcuts might put five pounds in your backpack if you choose to go in one direction (i.e., implement change A) but might put 30 pounds in your backpack if you choose another direction (i.e., implement change B).
At the abstract level, the backpack metaphor is not necessarily more apt than that of technical debt. Where it begins to add value however, is in the context of providing financial justification for investment in refactoring. The backpack metaphor highlights the idea that the value of addressing suboptimizations (i.e., the cost of technical debt) cannot be assessed from a static perspective. It can be quantified and expressed only in relationship to forward movement or change.
Providing rigorous financial justification for refactoring activities has always been a challenge. The backpack metaphor would indicate that this justification can be done only by considering potential future change cases. Dependency mappings between proposed refactorings and future user stories, together with cost and value calculations and the application of real-options heuristics could potentially provide a path forward.
Nanette Brown, SEI