Sound familiar? “We’re scared to touch that module.” “Every release is stressful.” “It works in test but not in prod.” “Only Dave understands how billing runs, and Dave is on holiday.”
Every team we meet has a version of these sentences. They get filed under one vague heading, technical debt, and then the conversation stalls. Engineers say the code is a mess. Leaders hear noise. Nobody agrees on what to fix first, so nothing gets fixed at all.
The problem isn’t that teams don’t care about technical debt. It’s that “technical debt” has become a single word doing the work of thirteen. When everything is debt, nothing is prioritised. You can’t pay down a balance you can’t itemise.
So this is the itemised bill. Researchers Alves and colleagues spent a paper doing what most teams never do: naming the distinct kinds of debt a software system accumulates. Their ontology lands on thirteen types. We use that same map with the teams we work with, because once you can point at the specific type of debt that’s slowing you down, the argument about “should we invest in quality” turns into a much better argument about “which of these thirteen is costing us the most this quarter.”
First, a definition that fits on a napkin
Before the thirteen, the one. Here is the definition we keep coming back to:
Technical debt is anything that impacts throughput or stability.
Nine words. Throughput is how quickly and often you can ship a change. Stability is whether that change survives contact with production. If something in your stack is slowing down delivery or making releases riskier, it’s debt, whatever label an engineer puts on it. If it isn’t touching either of those, it might be ugly, but it isn’t costing you, and it can wait.
That definition matters because it connects every type below to a number a leader already tracks. The four DORA metrics, change lead time, deployment frequency, change fail rate, and failed-deployment recovery time, are just throughput and stability with a ruler held up to them. Each type of debt degrades at least one of them. Keep that in mind as you read: the point of naming the debt is to see where your throughput and stability are leaking.
The 13 types
Think of these less as thirteen separate diseases and more as thirteen places a house can rot. Some you’ll spot from the street. Some only show up when you open a wall.
1. Architecture debt
This is the debt built into the shape of the system itself: violations of modularity, tangled dependencies between components that should never have known about each other, a structure that made sense for the product you had five years ago and fights the product you have now. Architecture debt is expensive precisely because you can’t pay it off with a tidy afternoon of refactoring. It’s load-bearing. Touch one wall and three rooms shift.
So what? Architecture debt is the reason a “small” feature takes six weeks, because it can’t be added without threading through four systems that weren’t designed to talk. It throttles throughput at the root, and it’s the debt most likely to be quietly capping how fast your whole organisation can move.
2. Build debt
This is friction in the process of turning code into a running artifact: brittle build scripts, unnecessary steps, dependencies that take twenty minutes to resolve, a pipeline only one person knows how to fix. Every developer pays this tax several times a day.
So what? A slow or flaky build multiplies across every engineer, every commit, every day. It’s a small number times a very large number. Build debt is a direct, measurable drag on deployment frequency, and it’s often one of the cheapest types to fix relative to the time it gives back.
3. Code debt
The classic. Problems in the source itself: duplicated logic, functions that sprawl across hundreds of lines, naming that hides intent, the code smells that make a file hard to read and harder to change safely. This is the debt most people mean when they say “technical debt,” even though it’s only one of thirteen.
So what? Code debt raises the cost of every future change and the odds that a change breaks something. Poor legibility is why onboarding takes months and why a two-line fix comes with a three-day risk assessment. It quietly erodes both throughput and stability at once.
4. Defect debt
These are the known bugs you’ve decided not to fix yet. Not the ones hiding in the dark, the ones already logged, triaged, and consciously deferred because something else was louder. A backlog of known defects is a debt with a running interest rate.
So what? Deferred defects don’t sit still. They interact, they generate support tickets, and they erode trust with the customers who keep hitting them. Every known bug you carry is a small, permanent tax on stability and on your support team’s time. Left long enough, the interest exceeds the original principal.
5. Design debt
Design debt lives one level above the raw code and below the architecture: the accumulated violations of good design practice you find when you look at how the pieces are put together. Objects that know too much about each other, missing abstractions, patterns applied where they hurt and absent where they’d help.
So what? Design debt is what makes a codebase rigid. Changes that should be local ripple outward, because the seams aren’t where they should be. It’s the reason a team’s velocity mysteriously halves as a system matures, even though the same people are working just as hard.
6. Documentation debt
Missing, thin, or out-of-date documentation anywhere it matters: no runbook for the deploy, a design doc that describes a system three rewrites ago, an API with no examples, comments that lie because the code moved on without them. Outdated documentation is often worse than none, because it confidently points people the wrong way.
So what? Documentation debt turns knowledge into a bottleneck. Work waits on the one person who remembers, and decisions get made on guesswork. It’s a direct hit to throughput that hides as “just how long things take here,” and it compounds every time someone new joins or someone experienced leaves.
7. Infrastructure debt
Suboptimal or outdated infrastructure and the processes around it: underpowered environments, manual steps that should be automated, a staging setup that doesn’t resemble production, tooling a version or five behind. It’s the plumbing, and like plumbing, you notice it most when it fails at the worst possible moment.
So what? Infrastructure debt slows everything downstream of it and adds risk to every release. When test doesn’t match prod, “it works in test but not in prod” stops being a joke and becomes your Friday night. It degrades both delivery speed and the reliability of what you deliver.
8. People debt
Debt doesn’t only live in systems. It lives in teams: expertise concentrated in one or two heads, training that never happened, hiring that was delayed until the gap became a crisis. When only Dave understands billing, Dave isn’t an asset, he’s a single point of failure who also wants to take a holiday.
So what? People debt caps throughput in a way no refactor can fix. Work queues behind scarce knowledge, and every departure risks taking a critical system’s only maintainer with it. It’s the type leaders are best placed to pay down, and the one most often ignored until it walks out the door.
9. Process debt
The way of working that once fit and no longer does: ceremonies that produce nothing, approval chains built for a smaller and more fragile system, handoffs that add days and no value. Process debt is a Ferrari being driven like a Toyota Corolla, a capable team held to habits designed for a slower, riskier era.
So what? Process debt is pure throughput loss with none of the payoff. It’s the meetings and gates and sign-offs that add lead time without adding safety. Because it feels like “how responsible companies operate,” it survives long after it stopped helping, quietly setting a ceiling on how fast good people can deliver.
10. Requirement debt
The gap between the requirements you should have built and the ones you actually did: trade-offs made under deadline, a spec half-implemented, a feature shipped at seventy percent because the last thirty was expensive. Over time these partial decisions accumulate into a product that doesn’t quite do what anyone intended.
So what? Requirement debt shows up as rework and as features that technically exist but don’t satisfy the customer, which means they get rebuilt. It’s throughput spent twice on the same outcome, and it’s often invisible on any engineering dashboard because the code looks finished.
11. Service debt
The debt that comes from the external services and third-party integrations you depend on: a web service chosen for speed that no longer fits the functional or non-functional needs, an integration that constrains you, a vendor whose limits are now your limits. In a world built on APIs, someone else’s decisions become your debt.
So what? Service debt caps what you can offer and how reliably you can offer it, and often you can’t refactor your way out because you don’t own the code. It’s a stability risk you inherited, and the cost of switching only grows the deeper the dependency runs.
12. Test automation debt
The automation you haven’t written: functionality that works today but is only verified by hand, or not verified at all. Test automation debt is the missing safety net under continuous delivery. Every manual check is a step you must repeat, carefully, forever.
So what? Without automated tests, every release is slower and scarier, because confidence has to be manufactured by hand each time. This debt sits directly on top of both throughput and stability: it’s why teams batch up changes, delay deploys, and still ship regressions. Paying it down is often the single highest-leverage move a team can make.
13. Test debt
Related but distinct: weaknesses in the testing itself. Thin coverage, tests that assert too little, whole risky paths that were never planned to be tested, suites that pass while the important cases go unchecked. Test automation debt is about tests you didn’t automate; test debt is about tests that don’t do their job.
So what? Test debt is stability debt wearing a green tick. It gives false confidence, which is more dangerous than no confidence, because teams ship believing they’re covered. The failures land in production instead of the pipeline, where they cost more to find and far more to fix.
Two questions that turn a list into a plan
Thirteen types is a good map, but a map isn’t a route. Two questions turn it into one.
The first is Martin Fowler’s, and it’s about how the debt got there. Was it deliberate or inadvertent, prudent or reckless? Deliberate, prudent debt is a business loan: “we’ll ship the simple version now and refactor next quarter, and we know the interest.” That’s a defensible decision. Reckless, inadvertent debt is the power socket someone installed in the shower because it was the quickest spot. It wasn’t a decision at all, just an absence of one. The type of debt tells you what you have. The quadrant tells you how worried to be about how you got it.
The second question is the one that actually sets priorities: which of these is costing us the most right now? Not which is ugliest, which is most expensive. A wall of code debt in a module nobody has touched in three years is costing you almost nothing. A single point of people debt sitting on top of your billing system is costing you sleep. The definition does the sorting for you. Follow the throughput and stability. The debt that’s leaking the most is the debt you pay down first.
What to do differently on Monday
You don’t need a transformation programme. You need to stop treating one word as thirteen problems.
Take your team’s running list of “tech debt” and sort each item into one of these thirteen types. The act of sorting is where the insight lives, because you’ll immediately see the clusters. Maybe half your list is test automation debt, which means your real problem is confidence, not code. Maybe the scariest items are all people debt, which no refactor will fix but a deliberate knowledge-sharing effort will. Then, for each cluster, ask the throughput-and-stability question and rank by cost, not by irritation.
That’s the whole method. Name it, connect it to throughput and stability, pay down the expensive debt first, and repeat. The teams that do this don’t have less debt than everyone else. They just always know which debt is the one worth paying, and that’s the difference between a system that ages into a liability and one that endures.
Book an assessment
Most teams carry all thirteen types at once and can only feel the aggregate: releases are slow, changes are scary, and nobody can say exactly why. Enduring IT runs technical debt assessments that itemise the bill, map your debt to these thirteen types, and show you precisely where your throughput and stability are leaking and what it’s costing. Then we help you pay down the load-bearing debt first, and fix it once. Want to know which of the thirteen is really slowing your team down? Book an assessment with Enduring IT.