There Are Two Problems With Technical Debt: Technical and Debt

A few weeks ago I published an essay titled There Is No Such Thing as Technical Debt. I expected people to disagree. The phrase has been woven into software engineering for more than three decades, and questioning it was always going to provoke a reaction.

What I didn't expect was that many of the people explaining why I was wrong couldn't agree on what technical debt actually meant.

Some described deferred maintenance. Others argued it was knowingly taking architectural shortcuts to meet a deadline. Some pointed to functionality everyone knew would eventually need but intentionally chose not to build today. Others insisted technical debt was software that had always been intended as a temporary solution and would inevitably be rewritten. These weren't competing definitions of the same idea. They were different ideas sharing the same phrase.

That realization stayed with me long after the debate faded. Somewhere over the last thirty years, software engineering had quietly begun using technical debt to describe deferred maintenance, architectural compromise, temporary implementations, business prioritization, future expansion, and poor engineering. Those ideas overlap, but they are not interchangeable. The more I read, the less convinced I became that we were arguing over whether technical debt existed. It felt as though we had quietly stopped agreeing on what technical debt was.

And that led me somewhere slightly different from where I started. The problems we've spent thirty years calling technical debt are very real. Systems age. Shortcuts constrain us. Decisions that were rational five years ago become expensive to unwind. Architecture limits what a business can do next. The question isn't whether those problems exist.

The question is whether calling all of them debt has helped us understand who owns them.

The Problem With “Debt”

So I went back to Ward Cunningham, not because I believed I had misunderstood his original metaphor, but because I wondered whether the rest of us had gradually expanded it beyond recognition. Cunningham described a specific engineering trade-off: accepting a simpler solution today while recognizing that future changes might become more expensive. Martin Fowler later expanded that metaphor, distinguishing between deliberate and inadvertent technical debt, a framework that shaped how an entire generation of software engineers thinks about architectural compromise.

Both contributions remain enormously valuable. Cunningham wasn't wrong to give engineers language for a problem they were struggling to explain. But metaphors don't merely describe things. Once they become embedded in the way organizations think, they can begin to shape the thing they're describing.

Debt is one of those words whose meaning changes remarkably little across disciplines.

Debt: Something owed; an obligation to pay or return something.

Whether we're talking about a mortgage, a corporate bond, or a credit card, the underlying idea is the same. Value is received today in exchange for an obligation to repay that value in the future. Interest exists because repayment has been delayed. The legal documents may change. The mathematics may change. The principle does not.

One characteristic of debt is so obvious that we rarely notice it: repayment never creates new value. When I make my mortgage payment this month, I don't wake up with another bedroom. Paying off my car loan doesn't leave two cars in the driveway. A company retiring a bond doesn't suddenly own a second factory. Repayment settles an obligation that already existed. The value was received when the debt was incurred. Paying it back creates nothing new. It simply fulfills the agreement that made receiving that value possible.

The moment I applied that definition to the examples we routinely call technical debt, something no longer fit.

Future Cost Is Not Debt

One example appeared repeatedly in the discussion surrounding my earlier article. Imagine constructing a ten-story office building. The building is completed before opening day, but the elevator serves only the first two floors. Everyone involved understands that installing a ten-story elevator during construction would be far cheaper than extending it years later. The owner knows it. The architect knows it. The contractor knows it. Nobody disputes the economics.

The reason is straightforward: only the first two floors will be occupied for the foreseeable future. Extending the elevator to eight empty floors produces no business value, so the owner decides not to make the investment. If those upper floors are eventually leased, everyone understands expanding the elevator later will be more disruptive and more expensive. That possibility wasn't overlooked. It was consciously accepted because the investment didn't yet create sufficient value.

What interests me is that no one in construction would describe that decision as construction debt. More importantly, it doesn't satisfy the ordinary definition of debt. Nothing has been borrowed. Nothing has been promised. Nothing must be repaid. If the upper floors remain vacant, the elevator may never be extended. The future work isn't repayment for an earlier obligation. It's a new investment responding to a new business opportunity.

The elevator illustrates another distinction that surfaced repeatedly in the comments. Elevators require inspections, repairs, modernization, and eventually replacement. Those future costs are unavoidable. They are simply part of owning an elevator. Yet nobody mistakes those obligations for debt. They are the ongoing cost of maintaining a long-lived asset. Future obligation alone has never been enough to make something debt.

I recently found myself facing a surprisingly similar decision while rebuilding my own backyard. I'm considering an outdoor kitchen, though I have no immediate plans to build it. My contractor recommended preparing for it now while the patio is already under construction. Running utilities and reinforcing part of the foundation today would make the eventual project considerably less expensive. Waiting until I actually decide to build it will almost certainly require tearing out completed work before rebuilding it.

His recommendation is almost certainly the financially correct one. Yet choosing not to do it still doesn't create debt. If I eventually build the outdoor kitchen, I won't be repaying an obligation created years earlier. I'll be making a new investment because the project finally creates enough value to justify its cost. If I never build it, nothing has gone unpaid because nothing was ever owed.

The distinction matters because the decision about whether to prepare for that future kitchen isn't really a construction decision. My contractor can tell me what it will cost today. He can tell me what waiting is likely to cost later. He can explain the trade-offs and make a recommendation.

But he can't tell me whether an outdoor kitchen will ever create enough value for me to justify building one.

That's my decision.

Software should not be different.

What Exactly Is Being Repaid?

Every experienced software engineer has participated in some version of the conversation. A deadline cannot move. The business needs a capability immediately. Everyone understands that, given unlimited time and resources, the system would probably be designed differently. The team consciously chooses the simplest implementation that satisfies today's business need, fully expecting that one day it will be revisited or perhaps rewritten entirely.

At first glance, the comparison to debt feels almost perfect. We receive value today by shipping quickly while knowingly accepting that additional work awaits in the future.

But what exactly is being repaid?

If the software delivered the business value it was intended to deliver, then the original implementation accomplished its purpose. The company launched its product. Customers were served. Revenue was generated.

Five years later the business may look nothing like it did when that software was written. The customer base may have doubled. International expansion may introduce languages, currencies, and regulations nobody anticipated. Entirely new product lines may exist. The architecture that was perfectly reasonable for yesterday's company may genuinely be the wrong architecture for today's.

The rewrite may be enormously expensive. It may even cost more than building a more flexible architecture would have cost years earlier. Expense, however, has never been the defining characteristic of debt. Repayment is.

Repayment is a remarkably specific idea. It implies that today's expenditure settles yesterday's obligation. That's what paying off a mortgage does. It's what retiring a corporate bond does. You're paying for something you already possess. You aren't creating new value; you're satisfying an existing obligation.

Software rewrites rarely resemble that transaction. More often than not, the rewritten system supports customers, products, markets, regulations, and business models that simply didn't exist when the original software was written. It scales further. It integrates with systems that hadn't yet been imagined. It enables opportunities that weren't economically rational when the first version was built.

The organization isn't paying for what it already had. It's investing in capabilities it didn't previously possess.

That's why the distinction matters beyond semantics. If the original implementation fulfilled the business need that justified its existence, then the future rewrite isn't necessarily repayment. It may be expansion. It may be evolution. It may be a new investment responding to a different business than the one that existed when the original decision was made.

We've blended that conversation with another one about engineering quality. Was the software thoughtfully designed? Were unnecessary shortcuts taken? Did the team knowingly compromise quality when better alternatives were practical?

Those are legitimate engineering questions.

But whether an organization should spend additional money today for capabilities that create little immediate return but may become valuable years from now is a different question. Should it optimize for certainty or flexibility? Should it spend more today to reduce the potential cost of tomorrow? Should it build for the company it is or the company it hopes to become?

Those are product and business questions.

Calling both conversations technical debt quietly moves the second one into the first.

When the Language Becomes the Problem

Software engineering has been here before.

Story points emerged from a legitimate problem. Ron Jeffries recalls that early Extreme Programming teams estimated stories using "ideal days." The idea made sense inside the team, but stakeholders understandably struggled with being told that one ideal day of work might take roughly three actual days to complete. So the terminology changed. Ideal days became points.

The work hadn't changed. The estimation concept hadn't really changed. The language had.

Years later, Jeffries reconsidered what that language had helped create.

"I may have invented story points, and if I did, I'm sorry now."

His objection isn't that teams never needed to reason about the size of work. It's what happened after the terminology became institutionalized. Story points became something organizations tracked. Velocity became something they compared. Estimates became tools for predicting completion dates and, eventually, mechanisms for applying pressure. Jeffries argues that these uses can pull attention away from what actually matters: delivering small amounts of real value quickly.

The original problem was real. The attempt to describe it was reasonable.

But the language helped take organizations somewhere its creators never intended.

Technical debt deserves the same reconsideration.

Cunningham was describing something real. Engineers absolutely need to explain that today's implementation decisions can constrain tomorrow's choices. A shortcut can make future changes harder. An architecture optimized for the company we have today may become expensive when that company grows. Maintenance ignored for too long can make systems brittle. None of that disappears simply because we stop calling it debt.

The problem is what happened after we did.

Technical debt became something engineering has. It became an engineering backlog. Engineering leaders began talking about paying it down. Product teams began balancing feature work against technical debt work as though one created business value while the other merely cleaned up engineering's past mistakes.

The metaphor didn't just describe the cost.

It assigned the liability.

The Problem With "Technical"

This is where I think the language has done the most damage.

Engineers have always struggled to justify investments whose benefits are largely invisible. It's easy to explain why a company should spend money on a feature customers can see. It's much harder to explain why that same company should invest in architecture that enables a business it hasn't yet become, or infrastructure whose value may not be realized for years.

The language of debt solved that communication problem elegantly. Everyone understands debt. Everyone understands interest. The metaphor gave engineers a persuasive way to explain why postponing certain decisions could make future change more expensive.

But it came with an unintended consequence.

Once we call something debt, repayment begins to sound mandatory. More importantly, the modifier tells us who appears to owe it. Technical debt sounds like a technical obligation. The business may decide how much feature work gets funded, but engineering is left asking for time to "pay down" a liability that appears to belong to engineering.

That's backwards.

Engineering should absolutely identify the consequences of technical choices. Engineers should explain when an implementation is becoming harder to change, when maintenance is being deferred, when architectural constraints are beginning to limit product options, and when spending more today could reduce the cost of a likely future change. That's part of the job.

But once those trade-offs are visible, deciding whether to invest is not simply an engineering responsibility.

It is a product decision.

Sometimes the correct decision will be to invest now. Sometimes it will be to accept the higher future cost. Sometimes the future capability will never be needed and the supposedly shortsighted implementation will turn out to have been exactly right. Those are decisions about capital, opportunity, risk, and value. Engineering provides essential information, but engineering does not own the business outcome by itself.

That is the part of technical debt I think we've gotten wrong.

A few weeks ago I wrote that there is no such thing as technical debt. The reaction convinced me of something slightly different. The problems we've spent thirty years calling technical debt are very real. Systems age. Maintenance accumulates. Shortcuts have consequences. Architecture constrains future choices. Cunningham wasn't wrong to give engineers language for those problems.

The mistake was allowing the metaphor to become the model.

Story points should probably be a warning. A term created to improve communication eventually changed the behavior around the thing it described. Technical debt followed a similar path. What began as a way for engineers to explain the future consequences of today's decisions gradually became a category of engineering work, an engineering backlog, an engineering liability, and ultimately an engineering problem.

The problem was real.

The debt never was.

Because the moment we called it technical debt, business decisions quietly became engineering liabilities.