Technical Debt in Software Development: The Debt You Chose Versus the Debt That Happened to You

Every organisation running software it did not recently build is carrying technical debt. The question that never gets asked clearly enough is how it got there - because the answer determines whether anyone is to blame, whether the debt can be managed, and whether the right response is to fix it, live with it, or retire the system entirely. Technical debt in software development is not one thing. It is two, and treating them the same way is one of the more reliable ways to waste money on a problem you did not fully diagnose.

The term was coined by Ward Cunningham in 1992, in a note explaining why the team had shipped code they knew was imperfect. He used the financial analogy deliberately: a small debt, taken knowingly, can be a rational choice if you plan to repay it. The interest, he said, comes in the form of extra work in every future change. What he did not predict was that thirty years later, most organisations would be carrying debt they did not consciously take on, do not fully understand, and have no plan to repay. Those two categories, debt you chose and debt that happened to you, are worth keeping strictly separate.

What is technical debt in software development?

The original analogy is worth taking seriously, because it sets up the distinction that matters most. Financial debt is not inherently bad. A business takes on debt to fund growth, with an expectation that the return will exceed the cost of borrowing. The debt becomes a problem when the return does not materialise, when the repayment plan is ignored, or when the borrower did not understand the terms when they signed.

Technical debt works the same way, and the same failure modes apply. A team that chooses a simpler implementation to hit a release date, documents the trade-off clearly, and schedules a refactor in the next quarter has used debt as a tool. That is different, in kind and in consequence, from a team that inherited a system written for a business model that no longer exists, with dependencies on a database version the vendor stopped supporting in 2017, with documentation that was last updated when the person who understood it left.

The first kind of debt is a tool used deliberately. The second kind is an environmental condition. They require different responses, and conflating them produces the planning conversations that go nowhere: the meeting where engineering says "we need to address the debt" and the business asks "how much will it cost to fix?" and nobody can answer, because they are not talking about the same thing.

Gartner's application portfolio management research distinguishes between systems that are strategically invested in and systems that are simply running - what the TIME model calls "Tolerate" versus "Invest". A significant proportion of enterprise application estates sit in the Tolerate category not because a decision was made to leave them there but because nobody made a decision at all. The debt in those systems is not the product of a trade-off. It is the product of institutional inertia, and that is a management problem before it is an engineering one.

What is the difference between deliberate technical debt and accidental technical debt?

Martin Fowler's technical debt quadrant is the clearest framework for thinking about this. Fowler adds a second axis beyond deliberate versus inadvertent: prudent versus reckless. That gives four combinations. A deliberate and prudent decision sounds like "we know this is not right, but we need to ship, and we will fix it after launch." A deliberate and reckless one sounds like "we don't have time to design this properly." An inadvertent and prudent one sounds like "now we understand the domain, we can see we should have designed it differently." An inadvertent and reckless one is what most organisations discover in their legacy estate: code and structure that accumulated because no one was watching.

The business-level implication is this. Deliberate debt requires a repayment plan. Inadvertent debt requires a diagnosis before you can even write a plan. Both require time and money, but they enter the conversation differently. If you ask an engineering team to quantify the deliberate technical debt in a system, you will get an answer, because someone made a decision and probably left a note. If you ask them to quantify the inadvertent debt in a system that has been running since the previous administration, you will get a range that spans two orders of magnitude, because they are estimating the cost of work they have not yet fully explored.

This matters for how you fund the response. Deliberate debt can be treated like a known liability: you can put a number on it, schedule the repayment, and track whether it is being retired. Inadvertent debt is more like a building inspection on a property that has changed hands several times: the survey will find things nobody knew were there, and the final cost depends on what is behind the walls.

The organisations that manage technical debt well are the ones that have learned to distinguish between these categories in their reporting. The ones that manage it poorly tend to aggregate everything under "technical debt" in a backlog, with no attribution, no owner, and no repayment schedule - which means no progress, and no way to tell whether things are getting better or worse.

Why does technical debt accumulate even when no one intends it to?

The most common cause of significant, unmanaged technical debt in enterprise systems is not bad engineering. It is the gap between the context a system was built for and the context it is now operating in.

Consider a system built in 2008 to manage a specific workflow. The business has changed three times since then. The team that built it has moved on entirely. Two major refactors were started and abandoned when priorities shifted. A new integration was bolted on in 2015 to connect it to a CRM that was itself retired in 2020, and nobody fully removed the integration code because they were not sure what else it touched. The system still works, mostly. When something breaks, one person knows how to fix it.

That sequence of events is not a story of negligence. It is a description of how software ages in a live business. Every one of those decisions was reasonable in isolation. The problem is that no one was tracking the cumulative effect, and by the time the effect becomes visible, the original decision-makers are long gone and the institutional memory is a mix of folklore and outdated documentation.

Staff turnover is a significant accelerant. When the person who understands a system leaves, the debt that was invisible becomes invisible in a different and more dangerous way: not just undocumented, but undocumentable, because the knowledge no longer exists in the organisation. The Stack Overflow Developer Survey consistently shows that "dealing with legacy code" ranks among the top sources of developer frustration, year after year. That frustration is not about old code per se. It is about code where the reasoning behind decisions cannot be recovered.

Dependency drift is the other quiet accelerant. A system built on a framework version that was current in 2012 is now running on a foundation that the security community stopped updating years ago. The system itself has not changed, but its vulnerability profile has, and the cost of moving it forward grows with every year it stays behind. This is the category of debt that tends to convert from a maintenance inconvenience to a risk event - not gradually, but suddenly, when a vulnerability is disclosed and the upgrade path turns out to run through a component that was discontinued.

What does technical debt cost, and how should you measure it?

Vendor-commissioned research on the cost of technical debt tends to produce headline-grabbing figures, and they should be read with that origin in mind. A 2022 study commissioned by Stripe estimated that developers globally spend roughly 33 percent of their time dealing with technical debt and bad code. The methodology was a developer survey, not a financial audit, and the sponsor had a product to sell against that problem. Take the precise percentage with appropriate scepticism.

The underlying point, however, is directionally correct and matches what you will find if you simply ask your engineering teams where their time goes. The figure to establish in your own organisation is not the global average. It is the actual engineering hours consumed by workarounds, incident response, and testing friction in your specific systems. That number is usually recoverable from time-tracking data or sprint retrospectives, and it converts directly into salary cost.

There are three components worth measuring separately.

The first is the ongoing maintenance overhead: the extra hours required to make any change to a system because the codebase is difficult to understand, the tests are inadequate, or the deployment process is fragile. This is the interest payment on the debt, and it is paid on every sprint, not just when something goes wrong.

The second is incident cost. Systems carrying significant unmanaged technical debt tend to fail in unpredictable ways, because the connections between components are not fully understood. The cost of an incident includes not just the engineering time to fix it but the business disruption, the management time, and in some sectors the regulatory reporting obligation. These costs are rarely attributed back to the underlying debt.

The third, and most often overlooked, is the cost of business agility foregone. When a commercial team has an idea for a product change and the answer from engineering is "we can try that in Q3 at the earliest", that delay has a value. It may be the difference between catching a market window and missing it. It is very hard to calculate precisely, but it is real, and in fast-moving markets it is often the most significant cost of all.

A useful exercise is to take your three most significant business priorities for the next twelve months, then ask engineering which existing systems those priorities depend on, and what the realistic delivery timeline is. If the answer to any of them is "it's complicated", you have found where the debt is affecting business outcomes, and you have the beginning of a business case.

How do you decide whether to pay down technical debt, live with it, or retire the system?

This is where many modernization conversations go wrong. The engineering team presents a compelling case for a rewrite. The business approves it. Two years later, the new system is not live, the old one is still running in parallel, and the total cost is well above the original estimate. The Standish Group CHAOS reports have documented for decades that large IT projects fail at rates that should give any sponsor pause: in their 2015 report, only 29 percent of software projects were considered successful against the original scope, time, and cost criteria. The methodology measures project delivery, not business outcome, which is an important distinction - but the delivery record of large-scale rewrites is not strong enough to justify treating them as the default response to technical debt.

The decision framework is simpler than the debate around it usually suggests. You need three numbers: the annual cost of carrying the debt as it is today, the cost of addressing it (whether through refactoring, selective modernization, or full replacement), and a view on how the carrying cost will change if you do nothing. If the carrying cost over your three-year planning horizon exceeds the cost of addressing it, the financial case for intervention exists. If it does not, the case for leaving it alone is at least as strong.

"Leave it alone" is a real answer, and it is underrepresented in modernization conversations because the people who initiate those conversations usually have something to sell on the back of them. A system that is stable, fully understood, and not blocking any business priority is a system where the right answer is to monitor it, document it, and not touch it. The cost of an unnecessary modernization project is not just financial; it is also the risk of introducing new problems into something that was working.

The cases where intervention is clearly warranted are more specific. A dependency that will lose vendor support within your planning horizon creates a forcing function regardless of the carrying cost calculation. A system that is a bottleneck for a business priority you cannot route around requires a decision even if the carrying cost looks manageable. A system where the institutional knowledge is concentrated in one person who is approaching retirement creates a continuity risk that should be addressed before it becomes a crisis.

Konnectedly's assessment process starts here: separating the systems where intervention is warranted from those where the honest answer is to leave them alone, before anyone has a reason to prefer one outcome over the other.

What it does not do is recommend a specific build approach. The decision about whether to modernize and what to modernize is the work. How to build the replacement is somebody else's service, and conflating the two is exactly the conflict of interest that makes these decisions hard for most organisations to trust.

Frequently Asked Questions

What is technical debt in software development?

Technical debt in software development is the implied cost of rework created when a system is built or changed in a way that prioritises speed or convenience over a better long-term approach. It is called debt because, like financial debt, it accrues interest: the longer it is left unaddressed, the more expensive any future change becomes.

What is the difference between deliberate and accidental technical debt?

Deliberate technical debt is a conscious trade-off - a team chooses a faster approach knowing they will need to revisit it. Accidental technical debt accumulates without a decision: through staff turnover, shifting requirements, or simply never revisiting code that was written under constraints that no longer exist. The two require different responses.

Is technical debt always a sign that something went wrong?

No. Deliberate technical debt taken with a repayment plan is a legitimate business tool. A team that cuts a corner to meet a launch date, documents the trade-off, and schedules remediation work has made a reasonable decision. The problem is debt that is never acknowledged and never repaid, which is the category that grows silently.

How do you measure technical debt in a system you did not build?

You need three things: an inventory of where the debt sits, an estimate of what it costs to work around it today (in engineering hours, incident response, and delayed delivery), and a view of how that cost is likely to grow. Static code analysis tools can surface some of it, but the most revealing evidence usually comes from the team doing the work, not from automated reports.

When should a business pay down technical debt rather than live with it?

Pay it down when the cost of carrying it exceeds the cost of fixing it over your planning horizon, when it is blocking a business priority you cannot defer, or when a dependency it creates is about to become unsupported. Leave it alone when the system is stable, the workarounds are well understood, and no strategic change depends on touching it.

What does technical debt cost a typical organisation?

Estimates vary and most come from vendor-commissioned research, so treat them with caution. A commonly cited figure from a 2022 Stripe-commissioned study suggested that developers globally spent roughly 33 percent of their time dealing with bad code and technical debt. What it measured was self-reported developer time, not verified financial loss - but even if the true figure is half that, the cost is material.

Does retiring a system eliminate its technical debt?

Yes, but retirement has its own costs and risks. Migrating data, decommissioning integrations, retraining users, and managing the transition period all carry a price. Retirement makes sense when carrying the debt costs more than the total exit cost, or when the system is a dependency blocker for something the business cannot build around it. It does not always make sense just because the system is old.

Who is responsible for managing technical debt?

Ultimately the business owner of the system, not the engineering team alone. Engineers can identify and quantify the debt, but decisions about whether to carry it, pay it down, or retire the system require a business priority judgement that belongs to whoever controls the budget and the roadmap. Technical debt that never reaches a business owner is debt that will never be managed.