Misusing the Metaphor

John Allspaw

All technical disciplines (not just software development) require different shorthand terms or labels to represent complicated concepts. Metaphors are a popular type of shorthand; in software development, technical debt is quite a curious one that’s long overdue for revisiting. When Ward Cunningham originally coined the term “technical debt,” he used it as a metaphor to capture explicit decisions to write software such that it allows short-term progress to be “repaid” in the long term, through refactoring.

Since this coinage, however, the term has taken on many shapes and forms. Although many people continue to use the term in the way that Cunningham intended, many more use it to represent some amount of code that’s discovered (sometime later) to have faults that can, with the benefit of hindsight, be attributed to taking “shortcuts.” In this case, we can say that such code results not from explicit decisions but from the normal, everyday tradeoff judgments developers make.

If we write software to reflect our current understanding of the problem it’s intended to solve, the environment it will live in, and the set of potential conditions in which it’s expected to execute, we’ll make these judgment calls. Some of these judgments will be accurate enough to be called “correct”; some won’t. In other words, technical debt has come to mean a type of counterfactual judgment about code quality and can generate a koan-like question:

can you have technical debt without knowing you have it?

My main argument isn’t that technical debt’s definition has morphed over time; many people have already made that observation. Instead, I believe that engineers have used the term to represent a different (and perhaps even more unsettling) phenomenon: a type of debt that can’t be recognized at the time of the code’s creation. They’ve used the term “technical debt” simply be- cause it’s the closest descriptive label they’ve had, not because it’s the same as what Cunningham meant. This phenomenon has no countermeasure like refactoring that can be applied in anticipation, because it’s invisible until an anomaly reveals its presence.

We need a new term to describe this, because it’s not “technical debt” in the classic sense.