Invited article in IEEE Software – Technical Debt: Challenges and Perspectives

Earlier this year, I was asked to contribute to an article in IEEE Software, entitled “Technical Debt: Challenges and Perspectives.”

I can’t post the entire article here, but I can post the accepted text of my part of the article here.

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.

The cliff-hanger is that since I wrote the article, I’ve been working with some folks on what that new term could be. Stay tuned. 🙂

UPDATE: the new term is “dark debt” – via the Stella Report.


For citation purposes:

B. Stopford, K. Wallace and J. Allspaw, “Technical Debt: Challenges and Perspectives,” in IEEE Software, vol. 34, no. 4, pp. 79-81, 2017.
doi: 10.1109/MS.2017.99
keywords: {software engineering;software development;Best practices;Computer architecture;Information technology;Parallel processing;Software engineering;Software measurement;Ben Stopford;John Allspaw;Ken Wallace;software development;software engineering;technical debt},