Technical Debt Is Not One Thing: The Difference Between Debt You Chose and Debt That Crept In

Ask your engineering team to explain the technical debt in one of your core systems, and you will almost certainly get an accurate description of symptoms: slow deployments, fragile integrations, a test suite nobody trusts, a codebase where changing one thing breaks two others. What you will rarely get is an explanation of origin. How the debt arrived matters as much as what it costs, because debt that someone chose and debt that simply accumulated over time require completely different responses. Conflating them is why so many remediation programmes fix the wrong things first.

The phrase "technical debt" has entered the vocabulary of every steering committee that has sat through a modernization briefing. That is both useful and dangerous. Useful, because the metaphor works: like financial debt, technical shortcuts accrue interest, and that interest gets paid in engineering time whether you acknowledge the principal or not. Dangerous, because the metaphor flattens a distinction that changes everything about how you respond. Not all debt is the same debt, and in software development, the origin of the debt is the first diagnostic question anyone should ask.

What is technical debt in software development?

The term was coined by Ward Cunningham in 1992, initially to describe a specific and legitimate practice: shipping code that was not yet fully understood in order to get feedback, with the intention of refactoring it once that feedback arrived. His original framing, documented at Ward's Wiki, was about learning, not laziness. The debt was incurred to gain information faster, with the explicit plan to pay it back.

What happened over the following three decades is that the metaphor expanded to cover everything from rushed feature development to decade-old systems held together with integrations nobody designed. The word "debt" became a container for every engineering problem that did not fit into a sprint. And when you use the same word for all of it, you lose the ability to triage.

The original meaning - a chosen shortcut with a planned repayment - is a fundamentally different thing from code that degraded across five ownership changes and two platform migrations.

For a business leader, the practical implication is this: when an engineering team tells you the system carries significant technical debt, that statement alone does not tell you whether the organisation made a series of explicit trade-off decisions that were never revisited, or whether the system simply rotted because no one was watching. Those two situations require different funding conversations, different timelines, and different levels of urgency.

Why does the distinction between chosen debt and accumulated debt matter?

Chosen debt, in the most responsible version of the term, looks like this: a team faces a deadline, documents a known shortfall in design or test coverage, ships anyway, and creates a backlog item to address it. The debt is recorded. The interest rate is understood. The principal sits in a queue. The failure that turns this into a real problem is not the original decision - it is the absence of any mechanism to actually service that debt. The backlog item ages. The engineer who understood the trade-off leaves. Two years later, the item exists in a tracker nobody reads, the original context is gone, and the cost of addressing it has compounded.

Accumulated debt is different in kind. Nobody decided the integration between the billing system and the customer portal should be undocumented. Nobody chose to have the authentication logic duplicated in four different services. It happened because the system evolved under pressure, across teams with different conventions, over years when consistency was never enforced. There was no decision to point to because there was no decision. Accumulated debt is the product of drift.

The Gartner TIME model - which categorises applications as Tolerate, Invest, Migrate, or Eliminate - implicitly depends on this distinction, though it does not state it directly. A system in the "Tolerate" category is usually one where the debt is known, the system is stable, and the cost of carrying the debt is lower than the cost of addressing it. That is a reasonable position only if the debt has been characterised accurately. If you are tolerating a system because nobody has looked at it closely enough to understand what category of debt it carries, you are not making a decision. You are deferring one while paying interest.

How do you tell which type of debt you are dealing with?

This sounds straightforward and is not. Most engineering organisations, particularly those that have grown through acquisition or moved quickly during scaling phases, have incomplete records. A system that was built in eighteen months of intense pressure in 2016 may have almost no contemporaneous documentation. Asking "was this chosen?" and finding no answer does not automatically mean it was not - it may mean the records no longer exist.

A more reliable approach is to look at the shape of the debt rather than its provenance. Chosen debt tends to be concentrated: a known module that never got the refactoring it needed, a specific integration that was wired together quickly. Accumulated debt tends to be distributed: inconsistencies spread across the codebase, conventions that shift mid-system, dead code paths that nobody removed because nobody was sure they were dead.

When debt is concentrated, remediation is a targeted investment. When it is distributed, remediation is closer to a rebuild, and the conversation at the leadership level needs to reflect that.

The Strangler Fig pattern, documented by Martin Fowler, works well against distributed accumulated debt in live systems precisely because it allows incremental displacement without a point-in-time decision to rebuild everything. But the pattern is not universally applicable, and knowing whether your debt is concentrated or distributed is a prerequisite to knowing whether the approach makes sense for your situation.

What does technical debt actually cost the business?

The figure that circulates most widely in this space - that technical debt costs US organisations roughly $85 billion annually - comes from a 2018 report by Stripe, which surveyed developers and asked them to estimate the proportion of their time spent on maintenance work versus new development. The underlying number is a self-reported survey estimate, not an audited cost figure. It is worth quoting only with that caveat attached, because a CFO who takes $85 billion seriously as a benchmark will reasonably ask where it came from, and "a payment company asked developers how much time they waste" is not a satisfying answer.

What you can measure, in your own organisation, is simpler and more actionable:

Take a representative change - a standard feature addition of modest scope - and time how long it takes from decision to production in your most debt-laden system. Do the same for your cleanest system. The ratio between those two timelines is a proxy for your debt burden. If a change that takes two weeks in a clean system takes eight weeks in a burdened one, you are paying six weeks of engineering time per change as interest. At a loaded engineering cost of £800 to £1,200 per day depending on seniority and location, that is not an abstraction. It is a number that fits into a capital planning conversation.

The Stack Overflow Developer Survey consistently finds that developers name working with legacy code and poorly documented systems among their top sources of frustration. That survey covers hundreds of thousands of respondents across the industry. It does not assign a cost, but it tracks the prevalence. What it documents is that the problem is not confined to organisations that did something particularly wrong. It is a near-universal condition of software development at scale.

The more important observation for a business leader is that technical debt does not have a uniform interest rate. Some debt costs almost nothing to carry - a module that never changes, in a system whose interface is stable, may carry debt indefinitely without meaningful consequence. Other debt is in the critical path of every new initiative, and its interest compounds every quarter. Identifying which is which is the actual work. Generating a total debt estimate without that classification is a number in search of a decision.

When is the right answer to leave the debt in place?

This is the question that most modernization conversations avoid, because the people having them usually have an interest in building something new. The structural problem is well documented: the firm that tells you how much debt you have is often the firm that would be contracted to address it. That is not a character flaw in the individuals involved; it is an incentive architecture that produces a predictable bias toward action.

The cases where leaving debt in place is the right call are more common than the modernization industry acknowledges, and a decision to leave it in place made with clear eyes is worth more than a remediation programme launched because someone said the debt was bad without quantifying what bad means.

The conditions that favour leaving debt in place are:

The system changes infrequently and there is no business pressure to change that. A billing engine that runs the same logic it has run for eleven years, with two changes in the last three, may be debt-laden but its interest payments are small. The debt matters only when change is frequent.

The system's interface is stable. If what the system exposes to the rest of the estate is consistent and well understood, the internal chaos is contained. The debt does not propagate.

The remediation cost exceeds the carrying cost over a reasonable horizon. If addressing the debt would require six months of engineering time and the annual interest cost is two weeks, the maths does not support intervention, particularly if the system is likely to be retired within five years anyway.

The Gartner pace-layering model is useful here as a framing device, even if the application is imperfect. Systems of record - the core transactional engines of the business - change slowly by design. Technical debt in a system of record that is genuinely stable and whose function is not changing is a different problem from technical debt in a system of differentiation that the business is trying to evolve rapidly. Same word, opposite decisions.

How should a leadership team respond when technical debt is put on the agenda?

The first question - chosen versus accumulated - is diagnostic. If the engineering team cannot answer it, that is information. It means the debt has not been characterised, and any cost estimate or remediation plan built on uncharacterised debt is a guess with a Gantt chart attached.

The second question converts an engineering abstraction into a business cost. It does not need to be precise to be useful. An order-of-magnitude estimate - "we lose approximately three hundred engineering days a year to this system" - is enough to frame the investment decision.

The third question is about opportunity cost rather than cost in isolation. Technical debt that sits in a stable, unchanged part of the estate is a different priority from debt in the system your product team needs to extend next quarter. The former can wait. The latter is already costing you velocity on work you have already committed to.

The fourth question is the governance question, and it is the one most often skipped. Konnectedly's core position is that the firm which assesses an application estate should not be the firm building the replacement, because the incentive to find remediable debt in assessable systems is structural when those two functions are combined. That is not an accusation; it is a design flaw in how the advice market is usually structured. Knowing who benefits from the answer you are being given is part of reading the answer correctly.

Frequently Asked Questions

What is technical debt in software development?

Technical debt in software development is the accumulated cost of shortcuts, deferred maintenance, and design decisions that made sense at the time but now slow down or complicate every subsequent change. It is not inherently bad engineering. Some of it was a conscious trade-off. The problem is when no one can tell anymore which part was chosen and which part simply accumulated.

What is the difference between intentional and unintentional technical debt?

Intentional technical debt is a documented trade-off: a team ships a known shortcut to meet a deadline and plans to revisit it. Unintentional technical debt accumulates without anyone deciding anything, through staff turnover, changing requirements, and years of small compromises. The first is manageable. The second is what fills the backlog that never shrinks.

Who is responsible for technical debt in an organisation?

Intentional debt is the product of a decision, so someone made it. Unintentional debt belongs to no one, which is part of why it is hard to fund fixing. The more useful question for a leadership team is not who is at fault but which category makes up the larger share of their estate, because the remedies are different.

How do you measure the cost of technical debt?

There is no universally accepted formula. The most credible approach is to measure what the debt costs in time: how long does a standard change take in a debt-laden system versus a clean one? That gap, multiplied by your engineering cost and change frequency, gives an annual carrying cost the finance team can reason about without accepting an abstract metaphor.

Can technical debt be left alone without consequences?

Sometimes, yes. If a system is stable, changing rarely, and not on the critical path for new capability, the cost of carrying the debt may be lower than the cost and risk of addressing it. The decision to leave debt in place is legitimate. What is not legitimate is leaving it in place without knowing that is what you have decided.

How does technical debt affect non-technical stakeholders?

It shows up as delivery slowdowns, unexplained incidents, and the inability to integrate new tools without extensive custom work. Executives rarely see the debt itself; they see its symptoms. The gap between what engineering says a change will take and what the business expected is usually where debt is hiding.

What is the first step in addressing technical debt at the portfolio level?

Classify before you act. Before spending anything on remediation, establish what proportion of the debt was chosen and what proportion accumulated. That classification changes both the priority order and the type of intervention. Chosen debt that was never revisited is a process problem. Accumulated debt is an assessment problem. They need different answers.