Technical Debt: Are We Arguing About the Problem or the Name?
Recently, I have witnessed several surprisingly heated discussions about technical debt. Interestingly, the disagreement was rarely about how to reduce it, how much it costs, or how it affects engineering teams.
In fact, the disagreement was often about whether the situation being discussed qualified as technical debt at all.
In many cases, the objection came from experienced engineers whose careers were built on precision and careful use of terminology. To them, calling every legacy issue, every unresolved bug or every outdated component “technical debt” felt inaccurate.
The debate is not new, and it is worth examining because the term has become so widespread that people often use it without considering what it originally meant.
At Embedded Expertise, we occasionally describe part of our work as helping clients reduce technical debt. Before doing so, it is useful to clarify what we mean by the term.
The original meaning
The expression technical debt was introduced by Ward Cunningham in the early 1990s, when I was still a student. The idea was simple and powerful. Just as a financial loan allows a company to obtain something immediately in exchange for future repayments, a technical shortcut allows a development team to move faster today in exchange for future engineering effort.
Anyone interested in the original meaning should watch Ward Cunningham’s short presentation Debt Metaphor, available on YouTube. It is remarkable how much of today’s debate stems from interpretations that differ from Cunningham’s own explanation of the concept.
The key element of the metaphor is intent.
A team knowingly decides to implement a temporary solution, understanding that additional work will be required later. The shortcut is accepted because the immediate benefit outweighs the future cost.
This distinction matters.
Technical debt is not simply bad code. It is not an unexpected defect. It is not the result of poor engineering. It is a conscious trade-off between short-term delivery and long-term maintainability.
🪙 A team that duplicates code to meet a deadline and plans to refactor it later has taken on technical debt.
🪙 A team that postpones the creation of automated tests until after a release has taken on technical debt.
🪙 A team that ships a temporary workaround because a customer demonstration is approaching has taken on technical debt.
In each case, the future work is known at the time the decision is made.
How the meaning expanded
As the software industry adopted the term, its meaning gradually widened.
Today, engineers frequently use technical debt to describe almost any technical issue that has existed for a long time. An outdated operating system, an unsupported library, missing documentation, architectural weaknesses, cybersecurity vulnerabilities, build system limitations and even long-standing defects may all be labelled as technical debt.
This broader usage is understandable. The term has become a convenient way of describing the accumulated burden of past technical decisions.
However, it also moves away from Cunningham’s original definition.
Some engineers object to this broader usage because it departs from the original meaning. Others argue that language evolves and that the industry has collectively adopted a wider definition. Both positions are defensible.
The problem is that discussions can easily drift into a semantic crusade where engineers spend more energy debating the label than understanding the underlying liability.
What technical debt is not
One of the most common sources of confusion is the tendency to classify every undesirable technical situation as technical debt.
Consider a defect discovered six months after a product is released. The defect may be serious. It may be expensive to fix. It may have significant business consequences. Yet it is not technical debt.
Nobody intentionally created the defect in order to save time. Nobody consciously exchanged future effort for immediate progress. It is simply a defect.
The same reasoning applies to technological aging: a product running an old kernel is not automatically carrying technical debt. It may simply be an aging product following the normal lifecycle of technology. The mere existence of work to be done does not imply technical debt.
The grey areas
Reality, of course, is rarely that simple.
Suppose a product is based on an aging Linux kernel. Initially, this is merely the natural consequence of time passing. Eventually, however, security updates become increasingly difficult to obtain, maintenance costs increase and customer requirements evolve.
The engineering team understands that an upgrade is necessary. Management understands it as well. Yet, the work is repeatedly postponed because resources are allocated elsewhere.
Has the situation become technical debt? Reasonable engineers can debate.
Some would argue that the original aging process was not debt, but that the deliberate decision to defer corrective action created debt. Others would describe the situation as a maintenance backlog rather than technical debt.
The answer depends largely on how strictly one interprets the original definition.
The same ambiguity appears in many engineering discussions. A refactoring that was deliberately postponed, an architecture that no longer scales, a BSP that has become difficult to maintain, a cybersecurity backlog that continues to grow or a deployment process that depends on undocumented tribal knowledge may or may not qualify as technical debt depending on the definition being used.
These discussions can be useful. Precise terminology has value. However, there is a point at which the discussion ceases to improve understanding and becomes a semantic crusade. At that stage, the debate is no longer helping the organisation decide what to fix, when to fix it, or how much it is costing.
The label matters less than the liability
In practice, organizations rarely suffer because they chose the wrong label. They suffer because complexity, risk and maintenance costs accrue faster than they can manage them.
Whether those liabilities originate from technical debt, architectural erosion, aging infrastructure, cybersecurity weaknesses or accumulated maintenance backlog makes little difference to the engineers tasked with recovering control of the situation.
The practical questions remain the same:
- What are the root causes?
- What risks do they create?
- What is the cost of doing nothing?
- What recovery paths are available?
- Which actions should be prioritised?
These questions are usually more valuable than deciding whether a particular issue deserves the technical debt label.
Beyond technical debt
At Embedded Expertise, we are often called when a product or platform has become difficult to evolve. Sometimes the root cause is technical debt in the strict Cunningham sense. More often, it is a combination of factors: architectural decisions that no longer fit current requirements, obsolete software components, cybersecurity concerns, undocumented knowledge, performance limitations or simply years of accumulated complexity.
The terminology matters far less than understanding the situation accurately.
Whether an issue qualifies as technical debt, technical liability or something else entirely, the objective remains the same: diagnose the problem, understand its impact, and define a realistic path back to a system that can be maintained, secured and evolved with confidence.
Enjoyed this article?
Embedded Notes is an occasional, curated selection of similar content, delivered to you by email. No strings attached, no marketing noise.
