Technical debt — types, managing: Question bank

The central term, then the symbols (glossary — read once)

Before any trap, here is the central idea and every symbol/jargon word this page uses — each in plain words, plus a plain-English fallback for anyone who cannot render the math.

Definition The four quantities in the repay rule

$C_{0}$ = the cost (in effort: developer-days or story-points, not money) of making one future change if the code were clean. Plain English: "days a change would take with tidy code."
$i$ = the interest rate — the fraction by which the mess makes each change slower. $i = 0.5$ means "the mess makes a change take 50% longer than clean code would." Plain English: "the slowdown fraction."
$n$ = the number of future changes that will touch this messy code. Plain English: "how many times we'll come back to it."
$P$ = the principal — the one-time cost (in effort) to fix the shortcut properly so future changes are clean again. Plain English: "days to clean it up, paid once."

Plain-text form of the repay rule: fix the debt when (fix-once cost) is less than (number of future changes × clean-change cost × slowdown fraction). In symbols that is $P < n C_{0} i$ .

Definition Jargon you'll meet in the answers (all defined here)

Boy-Scout Rule — "always leave the code cleaner than you found it": whenever you edit an area, tidy it a little, so debt is repaid in tiny continuous amounts instead of one scary big refactor.
Refactoring — changing the internal structure of code to make it cleaner/easier to change without changing what it does. This is how the principal $P$ actually gets paid. (Go further: Refactoring.)
Coupling — how much one piece of code depends on the internals of another. High coupling = changing A forces you to change B, C, D too, so $i$ and $P$ are large. (Go further: Coupling and Cohesion.)
Cohesion — how much the things inside one module belong together. High cohesion = a module does one clear job. Low coupling + high cohesion = easy-to-change code.
Assertion-free test — a "test" that runs the code but never actually checks the result (no assertion), so it passes no matter what the code does — it gives false confidence.
CI (Continuous Integration) — a robot that automatically builds and tests your code on every commit. Slow/manual CI charges interest on every change. (Go further: Continuous Integration.)

Why the repay rule $P < n C_{0} i$ is true (build it from zero)

The whole page hinges on one inequality, so here is where it comes from — with a picture that builds it up one change at a time.

Formula Deriving the rule

WHAT one messy change costs: clean would cost $C_{0}$ ; the mess adds the fraction $i$ , so one change costs $C_{0} (1 + i)$ . The extra part — the interest on that single change — is $C_{0} i$ . WHAT $n$ changes cost in interest: the same extra is paid once per change, so total interest is $Interest_{total} = n times C_{0} i + C_{0} i + \dots + C_{0} i = n C_{0} i .$ WHY this is simple accumulation, not compounding: each change pays interest on the same fixed mess — the mess does not grow by paying it — so the terms just add ( $n C_{0} i$ ). It is not $(1 + i)^{n}$ ; there is no "interest on interest." (When people say debt "compounds" in practice they mean new debt piles on old debt, raising $i$ and $n$ over time — a real effect, but a different mechanism from financial compounding.) THE DECISION: if instead you pay the principal $P$ once, all later changes cost only $C_{0}$ (no interest). So paying is cheaper exactly when the interest you'd avoid beats the fix cost: $Pay when P < n C_{0} i .$

Walk the figure change-by-change (this is the new intuition, not just the formula): the yellow bars are stacked one per future change — each new change adds another block of height $C_{0} i$ to the interest tower, so you literally see interest grow step by step. The flat blue line is the principal $P$ : you pay it once, so it never grows. For the first few changes the yellow tower is below the blue line — carrying the debt is cheaper. The moment the tower's top crosses the blue line (the red marker) is the break-even change; from there on, every extra block is pure waste you could have avoided by paying $P$ .

Fowler's quadrant — walked through with a real ticket

Several traps below hinge on classifying debt. Here is the two-axis map, and — crucially — a worked classification so each corner is shown in action, not left for you to infer.

Read the figure: the horizontal axis is did we choose it on purpose? (Inadvertent ← → Deliberate); the vertical axis is did we do it with care/a plan? (Reckless ← → Prudent). The four corners are each labelled with a real quote, and the healthy corner is boxed in green.

Worked example Drop one real ticket into every corner

Take the same situation — "we skipped writing tests" — and see how the reason decides the corner (the green dot on the figure marks the good outcome):

Deliberate + Reckless (bottom-right, red): "No time, just ship it" — chosen on purpose, but no plan, no ticket. Trouble.
Deliberate + Prudent (top-right, green ✓): "We chose to skip tests to hit the demo, logged a ticket to add them next sprint, and we know the risk." Healthy, managed debt.
Inadvertent + Reckless (bottom-left, red): "Tests? We didn't think we needed any" — didn't know better and were careless.
Inadvertent + Prudent (top-left, yellow): "We shipped without tests; now we've learned we should have had them, so we'll do better." Honest learning debt. The lesson the figure teaches: the code is identical in all four — only the intent and the plan move you between corners.

True or false — justify

All debt is bad and should be avoided.

False. Some debt is optimal — deliberate-prudent debt lets you ship value now; for code you'll rarely touch again, the fix cost

P

exceeds the interest you'd ever pay, so cleaning it loses money.

Technical debt and a bug are the same kind of problem.

False. A bug is wrong behaviour; debt is working code that is costly to change. You can have zero bugs today and still carry huge debt (a clever rushed feature with no tests).

If code has no bugs, it has no technical debt.

False. Correctness and changeability are independent axes. Untested, tightly-coupled, undocumented code can be perfectly correct today yet be painful and risky to extend tomorrow — that pain is the debt.

Interest on technical debt is a one-time cost.

False. Principal is one-time (the fix); interest is recurring — you pay the slowdown fraction

i

on every future change that touches the messy code, which is why it accumulates as

n C_{0} i

across

n

changes.

Refactoring is always worth doing when you see messy code.

False. Worth it only when future interest beats the fix cost:

P < n C_{0} i

. Concretely, with

C_{0} = 2

i = 0.5

, fix cost

P = 6

: if

n = 3

then interest

= 3 \times 2 \times 0.5 = 3 < 6

, so leave it; if

n = 10

then interest

= 10 < ...

wait — interest

= 10 \times 2 \times 0.5 = 10 > 6

, so fix it. Same mess, opposite verdict, decided purely by

n

— see the break-even figure above.

Deliberate debt is always reckless.

False. "Deliberate" only means chosen on purpose; it can still be prudent if you know the consequences and track them (e.g. a logged ticket). It sits in the top-right corner of the quadrant figure, not the bottom-right.

Inadvertent debt means the team was careless.

False. Inadvertent means you didn't know better at the time — it can be prudent ("now we've learned how we should have layered this"), the top-left corner of the quadrant. Carelessness is the reckless axis, which is separate.

Adding more developers will pay down debt faster.

False (usually). Debt lowers changeability, so more people editing tangled, tightly-coupled code often create more merge conflicts and inconsistency. Repayment needs targeted refactoring, not raw headcount.

Skipping tests to hit a demo, with a ticket to add them next sprint, is reckless debt.

False. It's deliberate–prudent (the green ✓ corner): chosen consciously and tracked with a plan. The logged ticket is exactly what flips it from reckless to prudent.

A codebase with 100% test coverage has no test debt.

False. Coverage is a number, not a guarantee — flaky or assertion-free tests (which run code but never check its result) still create test debt because they don't give you confidence to change code.

Spot the error

"We can't measure debt because it's not money, so the

P < n C_{0} i

rule is useless."

The error is thinking the units must be currency.

P

and

C_{0}

are in effort (days/points) and

i

is a fraction — the rule works fine in developer-time; you never need real money.

"This module has interest

i = 0.5

, so we should fix it immediately."

The error is ignoring

n

. Interest rate alone decides nothing — total interest is

n C_{0} i

. If

n \approx 0

(dead-ish code), even a high

i

never gets paid, so don't fix.

"We eliminated all technical debt this quarter — great engineering!"

The error is treating zero debt as the goal. Over-cleaning cold code where

P > n C_{0} i

wastes effort and delays features; the target is the optimal debt level, i.e. control, not elimination.

"The metaphor is about money, so debt is a finance problem, not an engineering one."

The error inverts the point. The money framing exists to let engineers explain an engineering problem to business people; the underlying issue is changeability, owned by the team.

"We'll refactor later when we have free time."

The error is that debt makes every future change slower and new debt piles onto old, so 'free time' shrinks over time — a debt spiral. Fix: make repayment scheduled (Boy-Scout rule / reserved sprint %), never conditional on spare time.

"Dependency debt isn't real debt — the code still runs."

The error is equating "runs today" with "no cost." Outdated libraries accrue interest as security patches, breaking API changes, and rising upgrade difficulty ("software rot") — the longer you wait, the bigger the eventual

P

"A // TODO comment means the debt is being managed."

The error is confusing labelling with managing. A TODO makes debt slightly visible but with no owner, priority, or schedule it's ignored. Real management needs a tracked register + prioritisation + a pay-down plan.

Why questions

Why express debt as interest and principal instead of just "bad code"?

Because the financial framing captures the key insight the phrase "bad code" misses: the cost is recurring and grows with use, and there's a one-time price to stop it — this turns a vague complaint into a decidable trade-off (

P

n C_{0} i

Why does high-traffic code almost always justify repaying its debt?

Because

n

(number of future changes) is large, so accumulated interest

n C_{0} i

easily exceeds any fixed principal

P

— you pay the slowdown over and over on exactly the code you touch most. Picture the yellow tower in the break-even figure growing tall fast.

Why is the Boy-Scout Rule an effective repayment strategy?

It repays debt continuously and locally — you clean the small area you're already editing, so cost is amortised into normal work and debt never balloons into a scary, deferrable "big refactor." See the staircase figure below for the shape of this path.

Read the staircase figure: the red curve is "pay it all later" — debt climbs untouched, then drops in one terrifying vertical cliff (a risky big-bang refactor). The green staircase is the Boy-Scout Rule — many tiny down-steps as you tidy each area you touch, so debt hovers low and never requires a cliff. Same total work, far less risk.

Why can debt make a team's velocity fall over time even with no new features skipped?

Because interest is paid per change: as debt grows, each story costs a bigger fraction more, so the same effort yields less output — velocity silently decays.

Why does missing test coverage cause fear of changing code, and why is fear itself a cost?

Without tests you can't tell if a change broke something, so developers avoid or slow down changes — that hesitation and manual re-checking is the interest, even before any bug appears.

Why is "refactor-before-feature" often smarter than a separate refactoring project?

Because you clean exactly the area with proven upcoming

n

(you're about to extend it), targeting repayment where interest is guaranteed to be paid — a standalone project risks cleaning code no one will touch.

Why does slow/manual CI count as technical debt?

Because a slow build charges interest on every commit (waiting, context-switching, batching risky changes), and there's a one-time principal to automate it — same

P

n C_{0} i

logic, just in infrastructure.

Edge cases

What is the "debt" decision when

n = 0

(code you'll never touch again)?

Future interest

n C_{0} i = 0

, so any positive

P

makes repaying a pure loss — leave it. On the break-even figure the yellow tower never rises off the floor.

At exactly

P = n C_{0} i

(the break-even), should you pay or leave the debt?

In pure effort it's a tie, so the strict rule doesn't force a fix; but since repaying also cuts risk and fear (benefits the formula ignores), the practical guidance is lean toward paying at equality.

What if

P

is genuinely unknown or unbounded (a rewrite whose cost you can't estimate)?

You can't apply

P < n C_{0} i

directly, so don't commit to a full rewrite blind — de-risk by making small incremental repayments (the green staircase, not the red cliff) that give real data on

P

before deciding.

Can debt exist with

i = 0

(a shortcut that never slows future changes)?

No — then

n C_{0} i = 0

and there's nothing to pay interest on. Debt requires the mess to make future work harder; a shortcut with zero recurring cost is just a design choice, not debt.

Is it possible for adding tests to create debt rather than remove it?

Yes — brittle tests coupled to implementation details become test debt themselves: they break on every refactor, so their maintenance interest can exceed the safety they provide.

What happens to a debt item's classification once you notice it?

Inadvertent debt you've now spotted doesn't automatically become "good" — it becomes a known item you must consciously decide to keep (prudent) or fix. Awareness moves it out of the inadvertent (left) half of the quadrant into a deliberate choice.

If two debts have equal total interest

n C_{0} i

, which do you repay first?

Prefer the one with higher

i

and frequent near-term

n

, because the slowdown hurts sooner — but also weigh coupling: fixing debt that blocks other changes unlocks more value than the raw number suggests.

Is zero technical debt ever the right target?

Only for a tiny, safety-critical, rarely-changing system where any interest is unacceptable. For normal evolving software, chasing zero wastes principal on cold code — the optimum is a small, controlled amount.

Recall One-line self-test before you leave

Cover this: "When is keeping debt the correct, professional choice?" When ::: the future interest you'd avoid is smaller than the fix cost — formally $P \geq n C_{0} i$ , typically low- $n$ (cold or soon-deleted) code. Keeping it is prudent, not lazy.