Technical Debt in Software Development, Explained for the Person Paying

Technical debt in software development is the running cost of decisions that were taken for speed. Somebody chose the quick route — a block of logic copied instead of shared, a column bolted onto the wrong table, a rule hardcoded because the deadline was Friday — and the software worked. What changed was the price of every future change that touches that area. That price is the interest, and you pay it whether or not anyone tells you it exists.

I have spent ten years on all three sides of this: writing the code, running the delivery, then sitting opposite the person signing the invoice. The gap between those three views is where most of the confusion lives. Developers feel debt daily and rarely translate it. Clients feel only the symptom, which arrives as an estimate that looks wrong.

Where the term came from, and why it matters

Ward Cunningham coined it in a 1992 experience report about a financial software product. His framing was precise: shipping code before you fully understand the problem is like going into debt, and a little debt speeds development so long as it is paid back promptly. He also named the thing people skip — "every minute spent on not-quite-right code counts as interest on that debt."

The metaphor is useful for exactly one reason: it gives a finance-literate person a way to reason about an engineering decision. Debt is not automatically bad. Leverage is normal. What matters is whether you know you took it, what rate you are paying, and whether you have a plan to clear it before it compounds past your ability to service it.

Everything after this is that question applied to your project.

What technical debt in software development actually is

Strip the metaphor and it is one thing: duplicated or misplaced knowledge in the codebase.

When a business rule lives in one place, changing it is a small job. When the same rule has been copied into four screens, a background job and a report, changing it means finding all six, changing all six, and knowing you found all six. Nobody wrote the copies out of malice. They wrote them because the first version worked and the deadline was real.

The same pattern shows up at every level:

That last row is the one owners underestimate. Undocumented systems are debt held by a person rather than a repository, and people resign.

Some of it is a correct business decision

Martin Fowler's technical debt quadrant splits debt along two axes: deliberate versus inadvertent, and prudent versus reckless. His conclusion is the one worth carrying into a budget conversation — the useful distinction is not debt versus no debt, it is prudent versus reckless debt.

In practice that gives you four situations, and only two of them are your team's fault.

Prudent and deliberate. "We can ship the launch version in six weeks if we hardcode the pricing tiers, or twelve if we make them configurable. You have not sold this yet. Let us hardcode it and revisit once we know the tiers are right." That is a good decision. It is also the correct answer far more often than engineers like to admit, because building flexibility for requirements that never arrive is its own kind of waste.

Prudent and inadvertent. You learn things by building. Six months in, a better structure becomes obvious that nobody could have seen on day one. This is unavoidable, and a team that never hits it is probably not learning anything.

Reckless and deliberate. "We know this is wrong, we are doing it anyway, and we are not writing it down." This is the one to catch.

Reckless and inadvertent. Nobody involved knew there was a better way. This is a hiring and review problem, not a scheduling one.

The question to put to a delivery team is never "is there technical debt?" There is. It is "which of those four is this, and who decided?" A team that can answer without defensiveness is managing it. A team that treats the question as an accusation usually cannot answer it.

How it shows up on your invoice

You will not receive a line item called technical debt. You receive one of these instead.

"That simple change took three days." Anatomy of those three days: half a day reading the code to find where the rule actually lives, half a day discovering it lives in three places, half a day making the change, and a day and a half testing by hand — clicking through every screen that might be affected — because there are no automated tests to prove it. The typing was twenty minutes.

Estimates that keep growing for the same size of work. If a feature that would have taken a week in year one takes three weeks in year three, the product did not get more complicated. The cost of changing it did.

Fixes that do not hold. A bug gets fixed, then returns in a slightly different place. That is the signature of duplicated logic: the fix landed in one copy.

An upgrade quote that looks absurd. "We need three weeks to update a library" happens when the version gap is large enough that the upgrade path has become a rewrite. Nobody budgeted for the small, boring updates, so they arrived all at once as a big one.

Refusal to touch a component. When a developer says "I would rather not go near the billing module", that is not laziness. It is a risk assessment, and it is information.

A rising share of spend on keeping things working. If the proportion of your budget going to bugs and firefighting climbs each quarter while new capability shrinks, the interest payment is eating the principal.

Managing it versus drowning in it

The difference is visible without reading a line of code.

A team that is managing technical debt:

• Names the trade-off at the time it is made, in writing, in the ticket — not six months later in a retrospective
• Gives you estimate ranges with a reason attached ("three to eight days, depending on whether the report logic is shared or duplicated — we will know by Tuesday")
• Spends a visible, consistent share of every cycle on maintenance, and can tell you what that share is
• Updates dependencies on a schedule rather than in a panic
• Has automated tests on the paths where money moves, even if coverage elsewhere is thin
• Can deploy on a normal Tuesday afternoon without ceremony

A team that is drowning:

• Describes the codebase as "fragile" and treats that as a fact of nature
• Deploys only on Friday evenings, or only when it cannot be avoided
• Has one person who is the only one able to change certain areas
• Gives estimates that are large and unexplained
• Fixes the same class of bug repeatedly
• Proposes a full rewrite as the answer to a specific problem

That last point deserves its own note. A rewrite proposal is sometimes right and often a symptom — the team has lost the ability to reason about the system and would rather start again than read it. Before agreeing to one, work through the alternatives in our guide to legacy system modernisation strategies, because wrapping or incrementally replacing a system is usually cheaper and always less risky.

What to ask for in the delivery process

You do not need to audit code. You need the process to make debt visible so it cannot compound silently. Six asks, all reasonable, all answerable in a meeting.

1. A shortcut is recorded when it is taken. Not a vague TODO in the code. A ticket, in the same tracker as everything else, describing what was skipped, why, and roughly what undoing it involves. This costs a developer five minutes and converts invisible debt into a list you can price.

2. Maintenance has a named share of each cycle. Fifteen or twenty per cent is a common working figure, but the number matters less than the fact that it is explicit and protected. If maintenance is "what we do when there is spare time", there is never spare time.

3. Estimates come with the reason for the range. A single number hides everything. A range plus a cause tells you exactly where the debt is sitting, and over a few months those causes form a map.

4. Tests exist where the money is. Global coverage percentages are a poor target and easy to game. Ask instead which paths are covered: checkout, billing, permissions, anything that writes to a customer's records. On a system like HisaabKar, where a payment is allocated across the oldest outstanding invoices and stock is recosted on every invoice edit, those rules are exactly where an untested change does damage you only discover at month end.

5. Dependency updates are scheduled, not reactive. Small and regular, or large and terrifying. There is no third option.

6. Ask what breaks if the lead developer leaves tomorrow. The honest answer tells you how much of your system exists only in someone's head. If the answer is "quite a lot", the fix is documentation and pairing, and it is cheap compared with the alternative.

None of this requires a technical background to verify. You are checking whether the process produces a record, not whether the code is elegant.

When paying it down is the wrong call

This is the part most articles on the subject leave out, and it is where budgets get wasted.

Debt in code you never change costs you nothing. A module that has not been touched in two years and is not causing incidents is not a problem, however ugly it is. Refactoring it buys you a cleaner repository and no commercial outcome. Leave it.

A clean-up with no destination attached rarely changes delivery speed. "We are spending a quarter on tech debt" is not a plan. "We are consolidating the pricing logic because the three features on next quarter's roadmap all touch it" is. Pay down debt in the areas you are about to build in, and ignore the rest until that changes.

Sometimes the right answer is to stop investing entirely. If a system is being replaced next year, or the product line is being wound down, servicing its debt is spending money on an asset you are disposing of. Keep it secure, keep it running, and put the budget somewhere it compounds in your favour.

The same logic applies when a prototype meets production. We wrote up what actually gets rebuilt in that situation in our guide to rebuilding an AI-built app for production — the answer is rarely "everything", and knowing which parts survive is what keeps the cost sane.

The decision rule

Treat technical debt the way you treat any other borrowing. Take it deliberately when speed is worth more than the interest, record it the moment you take it, and repay it in the places you are about to build on. Ignore it everywhere else.

If you cannot get a straight answer about which shortcuts exist and what they would cost to undo, that is the finding. It is not a code problem at that point, it is a delivery process problem, and it will keep producing three-day estimates for one-hour changes until the process changes.

If you are weighing this up before a build rather than during one, the earlier decision matters more: the cleanest debt is the code you never commissioned. Our custom software vs off-the-shelf framework covers that fork, and if you have decided to build, custom software development and ongoing software development are where we handle the delivery side of it.