Technical Debt, A Metaphor Run Amok

Metaphor is the Root of Language

Technical debt is, of course, a metaphor. Like a picture, a good metaphor is worth a thousand words. In literature, whether poetry or prose, metaphor allows for compactness of language in the conveyance of feelings and ideas. It supplies color, nuance, tone, and context. It is analogy through imagery. I think it’s no exaggeration to say that metaphor is the root of language, that it makes communication between humans possible.

Metaphors often show up in the unlikeliest places.

The night was sultry.

Is this a metaphor? What do you imagine when you read this sentence? When I read it, I feel a hot August night, where the sun is long gone but the heat remains. I can feel the air around me: sometimes oppressive, sometimes a familiar embrace. It feels like a lovely metaphor because our current definition of “sultry” evokes this idea of sensuousness. That’s fair, I think, as this understanding of sultry is common in English since at least 1700. But prior to that, going back to the 1500s, sultry was typically used of the weather, as in, “oppressively hot, close and moist.” By this definition, our sentence might be no metaphor at all . . . or is it?

Sultry itself is derived from the word “swelter.” This seems consistent with our current understanding of swelter, which hasn’t changed much in modern times. Circa 1400, swelter meant “faint with heat.” So, maybe not a metaphor, but definitely different. Swelter itself is derived from the Old English “sweltan”, which meant “to die or perish.” So, we’re back to a metaphor, but the meaning has changed completely. However, sweltan comes to us from Proto-Germanic “swiltan,” which may have originally meant something like, “to burn slowly.” This would give our metaphor yet a different meaning.

As we can see, the metaphorical understanding of these words shifts over time. Concrete terms become redefined based on their metaphorical usage. You don’t have to look far to see that our language itself is built on metaphor. What will a reader of our sentence imagine a hundred years from now?

Given the ubiquity of metaphor, it’s no surprise that we turn to it so often to explain complex technical or scientific concepts. Metaphors are powerful. They allow us to explain the unknown in terms of the known. But the stakes for language are different in the sciences than they are in literature. In literature, the wrong metaphor merely renders the text opaque; it detracts from clarity, rather than contributing to it. In the sciences, the wrong metaphor may be far more dangerous.

In science, the real danger comes when the metaphorical context starts to drive reasoning about the underlying concept. In the pantheon of cognitive biases, this is known as the “framing bias.” Unfortunately, it is extremely difficult to avoid this bias. Like it or not, metaphors sway our opinions. Metaphors unconsciously color our reasoning. This is especially so when we allow ourselves to forget that they are metaphors.

The sciences provide numerous examples of this phenomenon, from the innocuous, to the confounding, to the outright deadly. One study that really resonates with me investigated the ways in which the metaphors used to describe crime in survey prompts influenced the subjects’ choice for the best strategy to address crime. When crime was described as a “beast/lurking,” participants were more likely to recommend traditional “enforcement” strategies, like more police and more prisons. However, when crime was described as a “virus/plaguing,” participants were more likely to choose social remedies, like educational and youth programs, or economic programs addressing poverty and employment.

Crime is a {wild beast preying on/virus infecting} the city of Addison. The crime rate in the once peaceful city has steadily increased over the past three years. In fact, these days it seems that crime is {lurking in/plaguing} every neighborhood. In 2004, 46,177 crimes were reported compared to more than 55,000 reported in 2007. The rise in violent crime is particularly alarming. In 2004, there were 330 murders in the city, in 2007, there were over 500.

In a stunning example of confirmation bias compounding framing bias, all participants were more likely to cite the crime statistics provided in the study prompts to support their positions, rather than the metaphorical framing used, even though the statistics were identical in both prompts. (Thibodeau PH, Boroditsky L (2011) Metaphors We Think With: The Role of Metaphor in Reasoning. PLoS ONE 6(2): e16782. https://doi.org/10.1371/journal.pone.0016782.)

Back to Technical Debt

I know this is all very interesting, but what does it have to do with technical debt? As a metaphor that has attained widespread currency, technical debt is an interesting case study of a “science” metaphor run amok. We all believe that we understand its meaning upon hearing it, but we fail to acknowledge that our understanding is necessarily colored by our pre-existing conception of and feelings about the term “debt.”

I would like to explore this topic by discussing four different types of technical debt. The first two are well known: the original meaning as coined by Ward Cunningham, and the common meaning that has superseded the original in general usage. The remaining two varieties are proposals I have to extend the metaphor of technical debt in new and, I hope, useful ways.

1) Earnest Exploration

This was Ward Cunningham’s conception of technical debt: the extent to which the programmers’ mental model of the business, and therefore the software they produce, is inconsistent with the actual business domain. In other words, the extent to which programmers “get it wrong” when they attempt to model a business in code. The reference to debt as a form of leverage is intentional. The programmers have an obligation to forge ahead in order to create a product to demonstrate, to put into production, and to receive feedback on. The debt is the risk they take of getting things wrong for the sake of making incremental progress.

The extent to which the software is allowed to remain “wrong” represents the “interest” on the debt. In Ward’s conception, the goal is to repay this debt as quickly as possible by incrementally bringing the software closer and closer to correctness. If the “debt” is never repaid, and the code remains inconsistent with the business, then more and more developer time will be spent fixing “bugs” and concocting work-arounds, until these tasks consume the budget and no other progress is possible. In short, Ward was using the metaphor to explain to his supervisors not only why the developers needed to forge ahead despite imperfect knowledge, but why they also needed to refactor the imperfect code continually. Failing to do so would eventually drown the project in “interest” on this unpaid “debt.”

2) Speed Over Quality

This is the most common understanding of technical debt. In dry, technical terms, it has been described as “a collection of design or implementation constructs that are expedient in the short term, but set up a technical context that can make future changes more costly or impossible” (Wikipedia). This definition of technical debt is intended to justify expediency over correctness. Speed over quality.

Of course, one person’s debt is another wannabe-tycoon’s leverage. Where Ward sought to caution stakeholders against risk, others see technical debt as a legitimate strategy to maximize profit: “I can use less of my money, borrow other people’s money, and boost my return!” The fallacy of this logic is that the “other” people are actually the future you, and the debt you incur today will impact your ability to answer the future demands of your business.

It’s most interesting to me that this metaphor is used to lend legitimacy to our actions that would not attach otherwise. Would we really feel the same about our “tech debt” if we referred to it as “quick and dirty code”? Or “hacky code”? Is there a difference? At some point, I think, we need to recognize that this conception of technical debt lies somewhere on the spectrum of the “move fast and break things” anti-pattern, and we each need to decide if we are willing to work and produce software in that context.

For Ward’s part, he is opposed to using the technical debt metaphor in this way. He had this to say in a video published to YouTube:

A lot of bloggers, at least, have explained the debt metaphor and confused it, I think, with the idea that you could write code poorly, with the intention of doing a good job later. And thinking that was the primary source of debt. I am never in favor of writing code poorly.

(Ward Cunningham, Debt Metaphor).

Unfortunately, telling someone how to use a metaphor is a lot like telling them what religion they are. It just doesn’t work. Like it or not, this definition of technical debt is the dominant understanding of this metaphor today. The best we can do is be honest with ourselves and not use it an excuse to push code that wouldn’t make our mamas proud. WWWD – What Would Ward Do?

The next two varieties of technical debt I would like to discuss are less commonly recognized under this metaphor, but I think are needed to round out our understanding of technical debt as a general term to describe the overall maintainability and extensibility of our code.

3) Code Entropy (AKA Bit Rot, or “I Can’t Bundle Update Because…”)

Code entropy is not a new idea (“software entropy” even has its own Wikipedia entry), but I propose to use this term specifically for the kind of technical debt that crops up over time in all software. Since no software exists in true isolation today, Code Entropy is the term to describe what happens when we fail to tend our software gardens. It is the recognition that neglect alone can cause software to eventually fail. Our languages evolve, dependencies change (or fail to change), even hardware itself can change to the point where software that worked yesterday will no longer run today. This conception of technical debt represents the acceptance that all code requires maintenance just to continue to function.

4) Mission Drift

The last form of technical debt I would like to discuss is Mission Drift. Mission Drift is the recognition that, no matter how correct the code may be at the time it is written, it is certain that over time it will inevitably deviate from the way the business currently runs. This is because the business itself inevitably changes over time. In more colorful terms, this is why “you have to put the email address in the fax number field, because this system was written on an AS/400 back when…” Just as with the meaning of “sultry,” the utility of our code will drift over time as the business context in which it was created evolves according to its own needs.

Like earnest exploration, avoiding mission drift requires constant dialog with the product users, and continual adjustments to keep the code aligned with their needs. Consistent with the other three species of technical debt discussed here, mission drift is the recognition that constant vigilance and constant effort are needed to keep code running, to maintain the utility of the code, and to minimize the future cost of change.

The Price of Metaphor is Eternal Vigilance

To wrap things up, consider the following observations:

It is impossible to carry out scientific explanation without metaphors. Indeed we can hardly speak without them. The most we can demand is that we be conscious of the metaphorical content of our words and not be carried away. . . . No metaphors are truly benign and without dangers. As Norbert Weiner observed, ‘The price of metaphor is eternal vigilance’.

Richard Lewontin, foreword to Susan Oyama, The Ontogeny of Information, 2nd Edition (Duke University Press, 2000).

This tension is obvious in our various uses of the term “technical debt.” Whether our “debt” is incurred as a result of earnest exploration, the need for speed over correctness, code entropy, or mission drift, this metaphor is useful because it accurately evokes both the burden of vigilance and the cost of neglect. However, the metaphor fails us, and becomes nothing more than a mechanism for subverting our values, when it is used glibly to justify unjustifiable behavior.

The best lesson we can take from this exploration, I think, is to be cautious in our use of metaphor to explain technical concepts. As Ward Cunningham learned, once the metaphor is out of the bag, it’s impossible to get it back in. In fact, “[t]he more vivid the image [the metaphor evokes], the more dangerously seductive and resistant to change it is” (Ball, P. A metaphor too far. Nature (2011). https://doi.org/10.1038/news.2011.115).

Perhaps, as a last resort when struggling to describe a complex idea, before straining too hard to find the perfect metaphor, we might consider just trying to explain what’s going on as clearly and honestly as possible.