Last updated on December 11th, 2018 at 11:21 am
The technical debt metaphor is both powerful and perilous. Its power lies in its ability to communicate the concept that some technological assets regarded as operational might—and probably do—need further attention. The peril arises when we think of this metaphorical technical debt as if it were a financial debt.
Ward Cunningham coined the technical debt metaphor in the context of developing a software asset [Cunningham 1992] [Cunningham 2011]. He observed that when the development process leads to new learning, re-executing the development project—or parts of the project—could lead to better results. For this reason, among others, newly developed software assets can contain, embody, or depend upon artifacts that, in hindsight, the developers recognize could be removed altogether, or could be replaced by more elegant, effective, or appropriate forms that can enhance maintainability, defensibility, and extensibility. To deploy the asset in pre-hindsight condition would entail an obligation to return to it in the future to implement the improvements revealed by that hindsight. That obligation is Cunningham’s conception of the asset’s technical debt.
This phenomenon is not restricted to newly developed software. It applies to all technological assets. And it applies to new development, maintenance, cyberdefense, and enhancement.
Cunningham was aware that he was using a metaphor to describe his situation, which is a common one in technological development projects—both software and hardware. He probably chose the debt metaphor because his audience was financially sophisticated. He was exploiting their knowledge of financial instruments to convey a concept that, from his perspective, properly belongs in the software engineering body of knowledge. Such uses of metaphors are not unusual.
For example, the concept of leverage, which originates in mechanics, captures the idea of mechanical advantage gained when one employs a rigid bar, resting on a fulcrum, to move a heavy or fixed object. When a lever is arranged so that A is the distance from the heavy weight to the fulcrum, and B is the distance from the fulcrum to the point of application of the force, one gains a force “multiplier” of B/A. This concept has been used in the world of finance, renamed financial leverage, to describe how borrowing can confer on the borrower a financial “force multiplier” by increasing the borrower’s total financial power. From there, the term leverage has spread into the general vocabulary of business. Indeed, we can now say that, “Cunningham leveraged his boss’s understanding of financial instruments to convey a concept that properly belongs in the software engineering body of knowledge.”
Metaphors are powerful.
And they are also dangerous. The danger arises when we rely on the audience to apply their experience to interpret the metaphor in the way we intend. But since the experience of every individual is different, we cannot be certain how the audience might interpret the metaphor. And that is where the trouble begins.
Before we undertake our exploration of the technical debt metaphor, we must investigate the structure of metaphors. This study will help us understand how the technical debt metaphor has evolved and how it continues to evolve. Even more important, a study of metaphors will help us understand and anticipate the communication problems that arise from the fact that the term technical debt is a metaphor. We’ll look at the structure of metaphors next time.
References
[Cunningham 1992] Ward Cunningham. “The WyCash Portfolio Management System.” Addendum to the Proceedings of OOPSLA 1992. ACM, 1992.
- Metaphors and the term technical debt
- Technical debt in software engineering
- Policy implications of exogenous technical debt
[Cunningham 2011] Ward Cunningham. “Ward Explains Debt Metaphor” (video; here; ).
- Metaphors and the term technical debt
- Technical debt in software engineering
- Policy implications of exogenous technical debt
