Somebody says the team needs time for technical debt. It sounds like an excuse, or at best like housekeeping that could reasonably wait until things are less busy.
It is neither, and the framing is more precise than the way the phrase gets used. There is an international specification for measuring technical debt, published by a standards body, built on surveys of what repairs actually take. It exists specifically because the concept needed to be expressed in terms a business could act on.
This article is that translation.
The metaphor is literal
The Object Management Group publishes an Automated Technical Debt Measure, developed by the Consortium for Information and Software Quality [1][2]. Its framing is the one worth borrowing, because it is exact rather than illustrative.
The cost to fix the structural quality problems in your software constitutes the principal of the debt. The inefficiencies those problems cause, such as greater maintenance effort or excessive computing resources, represent the interest [2].
Two consequences follow immediately.
You are paying the interest right now, whether or not you have ever discussed the principal. It shows up as estimates that have grown, changes that take longer than they used to, and more caveats attached to anything anyone touches.
And the interest is charged only on the parts you use. Debt sitting in code nobody has opened in three years costs you almost nothing. That single observation shapes almost every sensible decision about what to fix.
How it is actually measured
The standard is not a mood. It works by counting specific structural weaknesses in the code, applying an estimated repair effort to each one, adjusting for factors such as component complexity and how exposed the system is, and aggregating the result [2].
The repair estimates come from surveys of professional developers about what those fixes genuinely take [2]. The weaknesses themselves come from the same consortium's automated source code quality measures, which cover four areas: reliability, security, performance efficiency and maintainability [1].
So technical debt in this sense is not general untidiness or code somebody dislikes. It is a specific catalogue of structural problems, each with a known repair cost and a known consequence if left in place.
Most businesses will never run a formal measurement, and that is fine. The value of knowing the standard exists is that it tells you what kind of thing you are being asked about, and that a real answer to "how much" is possible in principle.
The signals you can see without reading code
Three, and your business already generates all of them.
Small changes take longer than they used to, with more caveats. The same size of request, quoted higher, hedged more.
Fixes cause unrelated problems more often. This is the clearest sign that the parts of the system are more entangled than anyone intended.
New people take longer to become productive. If it used to be two weeks and is now two months, more of the system has to be understood before anything can be changed safely.
Any one of those merits a look. All three together is a finding.
You can put rough numbers on it without any specialist tooling. Track how long a typical small change takes, month over month, and how often a change causes a problem elsewhere. If both are climbing, you have your answer in figures your own team already produces. Formal tools give you a more precise number, and precision is rarely the thing that was missing.
Not all of it is a mistake
Treating all debt as failure produces bad decisions in the opposite direction.
Deliberately taking a shortcut to hit a deadline or test an idea can be entirely correct, exactly as borrowing money can be correct. What makes it damaging is taking it without recording it, without a plan to repay, and without anybody tracking the interest.
The distinction that matters is between deliberate and accidental. Deliberate debt is a knowing choice, ideally written down: we are doing it this way to ship in March, and here is what we will owe. Accidental debt accumulates because nobody knew better at the time, or the requirements moved after the design was set, or the platform shifted underneath. The first is manageable because it is visible. The second is what surprises people mid-estimate.
And it is worth being clear that most debt is not caused by weak developers. It is caused by deadline pressure, changing requirements, moving platforms, and features added without anybody deciding what to remove. Competent people under those conditions produce debt reliably, which means the conditions are the thing to address.
That last cause deserves naming directly. Every feature adds a case that every future change must be checked against, so the cost of change rises with the surface area of the product. Our guide on saying no to a feature covers the mechanism. An unmanaged feature list and a rising maintenance bill are the same phenomenon viewed from two directions.
Where it comes from, concretely
Four sources account for most of it, and recognising which one you have changes the response.
The deadline that could not move. A date was fixed before the work was understood, so something had to give, and what gave was the parts nobody outside the team can see. This is the most common source and the most defensible one, provided somebody wrote down what was skipped. Usually nobody did, because the week it happened everybody was busy shipping.
Requirements that changed after the design was set. The system was designed for one shape of business and the business became a different shape. Nothing was done wrong. The structure simply no longer matches what it is being asked to do, and each new requirement gets bolted onto a foundation that was not laid for it.
The platform moved underneath. Frameworks change, browsers change, mobile operating systems set new requirements on a published schedule. Code that was entirely correct when written becomes non-standard by sitting still. This is the source people find hardest to accept, because it accumulates without anybody touching anything.
Features added without anything being removed. Every addition increases the surface area that every future change has to be checked against. This is the source most within your control and the one most often treated as somebody else's problem.
The reason to separate them is that only the first two respond to better engineering practice. The third needs a maintenance budget and a schedule. The fourth needs somebody with the authority to say no, which is a governance question rather than a technical one.
If you are trying to work out why a system that was fine three years ago is now expensive, it is usually the third and fourth acting together while everybody was watching for the first.
Where it ends if nobody acts
Old systems rarely fail dramatically. They consume.
The US Government Accountability Office reports that federal agencies typically spend about eighty per cent of their IT budget operating and maintaining what already exists rather than building anything new [3]. That is a US federal figure and your business is not a federal agency, so treat it as an illustration of where the ratio lands rather than as a benchmark.
The useful move is to calculate your own version. What share of your technology spend last year went on keeping things working, against building anything new? That single number is a better measure of your position than any code analysis, because it tells you how much capacity you have left for anything at all.
The same GAO review is worth noting for a second reason: several of the critical systems it examined were running with known cybersecurity vulnerabilities, precisely because modernisation kept being deferred [3]. Which brings up the one category that should not be managed as debt at all.
Security debt is a different queue
An unsupported dependency with a known vulnerability is not tidying work to be scheduled alongside refactoring. The consequence is not a slower delivery, it is exposure.
Keep it in a separate queue with a different urgency, and resist the temptation to bundle it into a general modernisation proposal where it will move at the speed of the least urgent item in the batch.
A worked example of the arithmetic
The abstraction becomes actionable once you put figures on it, and the figures do not need to be precise to be decisive.
Suppose your team makes roughly twenty changes a month to one part of a system. Two years ago each took about half a day. Today the same size of change takes a day and a half, because more has to be understood before touching anything and more has to be tested afterwards.
That is twenty extra days a month of effort you did not previously need. Whatever your team costs, that difference is the interest, and you are paying it every month regardless of whether anybody has raised the subject.
Now ask what it would cost to fix the specific structural problems causing it. Suppose the answer comes back as six weeks of work. You do not need the standard's formal measure to see the shape of that decision: six weeks of principal against twenty days a month of interest is a payback period short enough that deferring it is the expensive choice.
Run the same arithmetic on a part of the system your team touches twice a year and the answer inverts completely. The problems may be worse there, and you are barely paying interest on them, so repayment buys almost nothing.
That contrast is the whole decision framework. Not how bad is the code, but how much are we paying, where, and what would it cost to stop. Two teams can look at identical code and reach opposite and equally correct conclusions, purely because of how often each of them has to work in it.
Deciding what to repay
Do not fix all of it. You only pay interest on the parts you work in, so repaying principal in stable, untouched corners buys you nothing.
Overlap two lists. Where are the structural problems? And which parts of the system does your team change most often? The intersection is where you are actually paying interest, and where repayment pays back fastest.
Your version control history gives you the second list for nothing, and most teams have never looked at it. The files that change every month are where your money is going.
On how to do the work: continuous small repayment beats a large freeze. Fix the area you are already touching, update dependencies as you go, and improve the thing you are working in anyway. Stop-everything efforts tend to run long, produce nothing visible to the business, and make the next request impossible to get approved.
Fund it as a standing allocation rather than an occasional project. Our maintenance guide budgets fifteen to twenty-five per cent of build cost per year for keeping software alive, and repayment sits inside that. A team without a standing allocation will always have something more urgent, which is exactly how the position arrives where it is.
And track it visibly, in the same place as everything else. Debt kept on a private engineering list competes with nothing and gets done never. Listed alongside feature requests, with an estimate and a stated consequence of deferring, it at least gets weighed by the people making the trade.
When your supplier asks for refactoring time
They are usually asking because they are paying interest that you cannot see. From outside, all that is visible is that estimates have grown.
That does not mean the request should be waved through. Ask for a business case, in three questions.
Which parts of the system does this touch, and how often do we change those parts? What will be measurably faster or safer afterwards? And what happens if we defer this by six months?
Good answers are specific. If the answer to the third is "nothing much", you have permission to defer, and you now know that rather than guessing. If the answer is that a dependency loses support in November, that is a date rather than an opinion.
Talking to the people who hold the budget
Use the principal and interest framing directly. It is not a simplification for non-technical audiences, it is what the standard actually says.
We are paying a recurring premium on every change because of problems we could fix once. Here is roughly what that premium costs us a year. Here is what fixing the worst of it would cost. Here is the payback period, and here is what we would defer.
That is an ordinary investment conversation, and it is a far better one than asking for time to tidy up.
One thing this is not
Technical debt describes the internal condition of code you are actively working in. A legacy system problem is usually something else: an unsupported platform, skills you can no longer hire for, a system you cannot safely change at all.
The options differ, and our guide on rebuilding versus fixing an ageing system covers that decision. Worth noting there, though, that a rewrite clears existing debt and begins accumulating new debt immediately at the same rate, unless the conditions that produced the first lot have changed. If the deadline pressure, the missing maintenance budget and the habit of accepting every request all survive the rebuild, so does the outcome.
What to do this week
Two questions, an afternoon, no cost.
What share of your technology budget last year went on keeping things running rather than building anything new? And which parts of the system does your team dread touching?
The first tells you how much interest you are paying. The second tells you where the principal sits. Between them they will get you most of the way to a decision, and neither requires anybody to look at a line of code.
If you want the detailed version, a codebase and dependency review starts from around AED 4,000 with us, covering the structural condition, what is no longer supported, where the concentrated risks are, and a prioritised view of what is worth repaying against what to leave alone. Final pricing depends on scope, and these are our own figures rather than a market survey, since no official body publishes rates for this work.
References
- Object Management Group, Automated Technical Debt Measure specification
- Consortium for Information and Software Quality, technical debt standard
- US Government Accountability Office, Information Technology: Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems (GAO-25-107795)
- ISO/IEC 25010:2023, systems and software quality models
- SKIMBOX, mobile app maintenance cost in Dubai
- SKIMBOX, saying no to a feature
- SKIMBOX, rebuild it or fix it
The technical debt standard is published by the Object Management Group and developed by CISQ. Its underlying quality measures are described here from the consortium's own published material, since the standard's full text and the related ISO documents sit behind paywalls. The GAO figures concern US federal government systems and are cited for illustration rather than as a benchmark for private business.
