From the Trenches: Technical Debt as Backpack?

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

Advertisements

One response to “From the Trenches: Technical Debt as Backpack?

  1. There are several concepts you have touched on here. One of these is basic as well as important namely; “financial justification for investment “.

    From the point of view of a software system representing a financial investment, you want to ask yourself how many years you expect to get out of that system that will be productive? This should of course be directly related to the amount of effort you will be prepared to invest in that system. So for example if the system will be expected to have only a short life, the principle of “good enough” will hold, as perfection will come at a high cost.

    Some years ago I came across another angle to this issue in a company where I worked at that time. They followed the practice of capitalizing the product of their softwares’ development in their financial books. They then amortized such systems over a number of years. At the end of that period of amortization, the system was deemed to have paid for itself and the financial basis was in place for enabling its replacement by a newer successor, which would incorporate the up-to-date, modern technologies.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s