Technical Debt: What It Is and How Small Teams Pay It Down

Technical debt is the extra time every future change costs because of a shortcut, an old design or code that is not quite right. The shortcut is the principal; the slowdown you pay on every change that touches it is the interest. A little debt taken on deliberately can be a good trade, the same way a loan can be. The trouble starts when nobody writes it down, nobody pays it back and the interest quietly eats the week. For a small team the fix is plain: record each piece of debt as a task with the cost it causes, and spend a fixed share of every week paying the most expensive ones down.

The definition of technical debt, from the source

The metaphor comes from Ward Cunningham, in his 1992 experience report on the WyCash portfolio management system↗ (opens in a new tab). His words are still the best definition: “Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.” He goes on: “The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt.”

Two things in that passage get lost in later retellings. First, Cunningham presents debt as a tool, not a sin: shipping before you fully understand the problem is how you learn what the right design is. Second, the repayment is a rewrite that folds what you learned back into the code. Debt is not the same as bad code written carelessly; it is the gap between what the code says and what you now know.

The Software Engineering Institute at Carnegie Mellon, in the book Managing Technical Debt↗ (opens in a new tab) by Kruchten, Nord and Ozkaya, puts it in more formal terms: earlier design or code decisions, made under budget or schedule constraints, that increasingly impede evolution and innovation. The word that matters there is “increasingly.” Debt gets more expensive the longer it sits.

Principal and interest, in days

Martin Fowler’s short article on technical debt↗ (opens in a new tab) gives the arithmetic. A new feature would take four days in clean code, but a confusing module structure makes it take six. The two extra days are the interest. Cleaning up the structure would take five days, and that is the principal. For one feature, paying the principal first is the worse deal. If three more features will pass through the same module, it is the better one.

That gives you the only question worth asking about any piece of debt: how often do we pay interest on it? Ugly code nobody touches costs almost nothing. A slightly awkward function that every change goes through costs something every week. Fowler’s advice follows from it: pay the principal off gradually, cleaning up a little each time you work in the area, so effort lands where the code actually changes.

Examples of technical debt

Most debt is ordinary. These are the kinds a two-to-eight person team usually has:

• A copy-pasted pricing rule in three places, so a sales tax change has to be made three times and someone always misses one.
• A database column that stores two meanings, such as a status field that is also used as a flag for “imported from the old system.”
• Tests that are skipped because they were flaky, so nobody trusts a green build before a release.
• A library two major versions behind, where the upgrade gets harder with every month you wait.
• A manual deploy step that lives in one person’s head. The interest is paid every release, and in full when that person is on vacation.
• A feature flag that has been on for everyone for six months, with the old code path still in place behind it. The feature flags post covers that kind in detail.
• Missing docs for a setup step, so every new hire loses a day to it.

In agile teams, a common example of technical debt is the story accepted as done while it still needed tests or a cleanup. The definition of done exists partly to stop that: if cleanup is part of done, it cannot quietly become debt.

Four kinds of debt

Fowler’s technical debt quadrant↗ (opens in a new tab) sorts debt on two axes: deliberate or inadvertent, and prudent or reckless.

• Prudent and deliberate: the team decides an earlier release is worth more than the cleanup it will owe, and knows it is choosing the cost.
• Reckless and deliberate: the team knows better but skips the design work anyway, without weighing what it will cost later.
• Reckless and inadvertent: the team did not know a better way. Some people argue this is not debt at all, just a mess.
• Prudent and inadvertent: the code was good, and only after building it does the team see what the design should have been. Fowler calls this inevitable for excellent teams, and ties it to the kind of debt Cunningham described.

The quadrant is useful mostly for one reason: it tells you the deliberate kinds should never be invisible. If you chose the shortcut, you knew about it at the time, which means you could have written it down. The inadvertent kinds surface later, usually when someone says “this would have been easy if…,” and that sentence is the moment to file a task.

Track technical debt as tasks

Debt that lives only in people’s heads never competes fairly with new work. The fix is to file each piece as an ordinary task, in the same list as everything else, and to write it so the cost is visible. A good debt task answers four questions:

1. Where is it? The file, module or screen, specifically enough that someone else can find it.
2. What does it cost today? The interest: “every change to pricing needs three edits and a manual check” is a cost; “the pricing code is ugly” is an opinion.
3. How often is that cost paid? Every release, every new customer, once a year.
4. What would paying it down involve? A rough plan and a size, so it can be weighed against a feature.

Do not invent a new category of work for it. Debt that slows you down but works as intended is an improvement to something that exists; debt that produces wrong results is a defect. The reasoning for keeping to three kinds of work is in features, enhancements and bugs. File debt the moment you take it on, too: the deliberate shortcut in today’s pull request should come with a task that says what was skipped and why.

A budget rule for paying it down

The teams that keep debt under control do not run heroic cleanup quarters. They reserve a steady share of capacity and protect it. The size of the share is your call; what matters is that it is written down and kept. A rule a small team can hold to:

• Pick a share you will actually keep, such as one task in five that moves to in progress, and say it out loud at planning.
• Choose debt by interest paid, not by how ugly the code is. The awkward module you touch every week beats the ugly one nobody opens.
• Pay down where you are working. When a feature passes through indebted code, include the cleanup in that feature’s plan if it is small.
• Raise the share when the interest is visibly slowing you down, and lower it when it is not. Review it once a month.

Written budgets like this are common in operations. Google’s SRE book, in its chapter on eliminating toil↗ (opens in a new tab), describes an advertised goal of keeping toil below 50% of each SRE’s time, because toil “tends to expand if left unchecked.” Toil is repetitive manual work rather than debt, but the logic carries over: a cap nobody has written down is not a cap.

Can AI tools pay down technical debt?

Partly, and the vendors say so. AWS markets AWS Transform↗ (opens in a new tab) as agentic AI for modernization, with headlines about removing tech debt; its user guide lists mainframe, VMware and .NET modernization among the jobs it runs. Coding agents such as Claude Code and Codex can also take a well-written debt task, such as “replace the three copies of the pricing rule with one function and add tests,” and do most of the work.

The limit is the same as for a person: an agent can pay down debt that someone has found, described and sized. It cannot tell you which debt is costing you the most interest, because that is a judgment about your roadmap. Write the task so the cost and the scope are explicit, and review the result as you would any change; verifying AI-generated work covers how.

Keeping debt visible on a fenbs board

On fenbs every piece of debt is an ordinary task: an enhancement such as ENH-240 when it slows work down, a bug such as BUG-241 when it gives wrong results. There is no separate debt kind. The note records where the debt is and the interest it costs; the plan says how it will be paid down and is rewritten as you learn. Put the tasks in a category of your own, such as “Tech debt,” and filter the board by it when you plan the week.

• Size tells you what paying it down costs: XS is under an hour, L about a week, and XL means split it before anyone starts.
• Priority runs 1 to 10, 1 the most urgent, so a debt task paying interest every release can rank above a new feature.
• Link the debt task to the feature that created it with relatesTo, so the shortcut and its repayment point at each other.
• Your budget share is a rule, not a task: record it on the Decisions and rules page, where every connected AI assistant reads the rules before it touches the board.
• Already have a debt list in a doc? Add many takes a pasted markdown list and turns each line into a task.