Technical debt — types, managing: Worked examples

This page drills the repayment decision from the parent note until every possible input has been walked. The one weapon we use over and over is the rule of thumb:

Everything below is just this one inequality, poked from every angle. The figure is the whole page in one picture — study it before reading on.

Figure — Technical debt — types, managing

Read the figure carefully, because every example lands somewhere on it:

The flat coral line at height $5$ is your one-time fix cost $P$ . It is horizontal because $P$ does not depend on how many changes come — you pay it once, whatever $n$ is.
The rising lavender line is total interest $n C_{0} i$ . With $C_{0} = 2$ and $i = 0.25$ it climbs by $0.5$ days for every extra change, so it is a straight line through the origin with slope $C_{0} i$ .
The two lines cross at the black dot, $n = 10$ (that is Ex 3's break-even). Left of the dot the coral fix is dearer than the interest ⇒ keep the debt (labelled region). Right of the dot the lavender interest overtakes the fix ⇒ the mint-shaded "refactor wins" region.
Every worked example is really just the question "which side of that black dot am I on?"

The scenario matrix

Every case this topic can throw at you is one row here. Each worked example below is tagged with the cell it hits.

#	Case class	What makes it tricky	Example
A	Hot code ( $n$ large)	interest dwarfs the fix ⇒ repay	Ex 1
B	Cold / dead code ( $n \to 0$ )	interest ≈ 0 ⇒ never repay	Ex 2
C	The break-even point ( $P = n C_{0} i$ )	tie — the indifference boundary	Ex 3
D	Zero interest ( $i = 0$ )	clean-enough shortcut ⇒ never repay	Ex 4
E	Partial fix (fix lowers $i$ , not to 0)	compare two interest streams	Ex 5
F	Compounding / debt spiral ( $i$ grows over time)	why "later" never comes	Ex 6
G	Real-world word problem (money + velocity)	translate business talk into $P, n, C_{0}, i$	Ex 7
H	Exam twist (classify + decide together)	Fowler quadrant meets the inequality	Ex 8

Case A — Hot code: interest dwarfs the fix

Case B — Cold / dead code: never repay

Case C — The exact break-even (indifference boundary)

Case D — Zero interest: the harmless shortcut

Case E — Partial fix: two interest streams

Real refactors often reduce interest without eliminating it. The inequality changes: compare doing nothing against fixing and then paying the smaller leftover interest.

Worked example Ex 5 · cell E

A tangled reporting layer has $i_{now} = 0.5$ . A refactor costing $P = 4$ days would bring it down to $i_{after} = 0.1$ (not zero — some complexity is essential). $C_{0} = 2$ , $n = 8$ .

Forecast: the fix isn't perfect — does it still pay?

Cost if we do nothing: $n C_{0} i_{now} = 8 \times 2 \times 0.5 = 8$ days of interest. Why this step? Baseline pain we're trying to beat.
Cost if we fix: pay $P$ once, then interest at the lower rate: $P + n C_{0} i_{after} = 4 + (8 \times 2 \times 0.1) = 4 + 1.6 = 5.6 days .$ Why this step? A partial fix does not remove all future cost — you must include the leftover $i_{after}$ .
Compare: $5.6 < 8$ ? Yes ⇒ refactor. Net saving $= 8 - 5.6 = 2.4$ days.

Verify: the general rule for partial fixes is $P + n C_{0} i_{after} < n C_{0} i_{now}$ , i.e. $P < n C_{0} (i_{now} - i_{after})$ . Check: $4 < 8 \times 2 \times (0.5 - 0.1) = 6.4$ . ✓ (Note this reduces to the master inequality when $i_{after} = 0$ .)

Case F — Compounding: why "later" never comes

Earlier cases assumed $i$ is a fixed number. But debt often makes code worse over time — each unclean change piles on more mess, so $i$ grows. This is the debt spiral.

Worked example Ex 6 · cell F

A module starts with $i = 0.2$ , but each edit raises it by $0.1$ (edit 1 costs interest at $0.2$ , edit 2 at $0.3$ , edit 3 at $0.4$ , …). $C_{0} = 1$ , and we plan $n = 5$ edits. Fix cost $P = 3$ (freezes $i$ at $0.2$ afterward).

Forecast: a fixed-rate reading would say interest $\approx 5 \times 1 \times 0.2 = 1 < 3$ , so keep it. Does compounding flip that?

Sum the growing interest (do nothing): $C_{0} \sum_{k = 1}^{5} (0.2 + 0.1 (k - 1)) = 1 \times (0.2 + 0.3 + 0.4 + 0.5 + 0.6) = 2.0 days .$ Why this step? Each edit's interest rate is higher than the last — you must add them one by one, not multiply by a single $i$ .
Extend the horizon — spirals bite over many edits. Over $n = 10$ : rates $0.2, 0.3, \dots, 1.1$ , sum $= 6.5$ days. Now $P = 3 < 6.5$ ⇒ refactor. Why this step? With a fixed rate the interest line is straight; with compounding it curves upward, crossing $P$ sooner than you'd guess.
Decide (the lesson): waiting makes the fix more attractive, not less. "We'll do it later" quietly grows the very cost you're deferring.

Verify: arithmetic-series sum $\sum_{k = 1}^{5} (0.2 + 0.1 (k - 1)) = 2.0$ ✓ and for $n = 10$ the rates run $0.2, \dots, 1.1$ summing to $6.5$ ✓. The $n = 10$ interest ( $6.5$ ) exceeds $P = 3$ , confirming the flip.

Case G — Real-world word problem: velocity in money

Business people speak in velocity and money, not $i$ and $n$ . The skill is translation, and the trap is defining $i$ correctly.

Worked example Ex 7 · cell G

A manager says: "Our team ships 10 story points/sprint on clean code, but this legacy service drops us to 8 points/sprint. A dedicated cleanup would take one full sprint. We'll be building on this service for 6 sprints." One sprint costs the company $20{,}000. Should we cleanup?

Forecast: losing 2 of 10 points feels small — but over 6 sprints?

Fix the units first. Let one clean sprint be our unit of work, and let $C_{0} = 1$ sprint = the time to deliver one sprint's worth of clean output. In money that unit costs $20{,}000. Why this step? $C_{0}$ must be a cost per unit of work, exactly as in the master inequality — not a velocity. We pin the unit down before defining $i$ .
Define $i$ from the definition, not by guesswork. The definition: $i$ = fractional slowdown relative to clean cost. Clean code does one unit of work in $1$ sprint; the messy service needs $\frac{10}{8} = 1.25$ sprints for the same unit. So the extra time is $1.25 - 1 = 0.25$ sprints per unit, giving $i = \frac{messy time - clean time}{clean time} = \frac{1.25 - 1}{1} = 0.25.$ Why this step? This is the interest rate — the slowdown measured against the clean cost $C_{0}$ , matching Ex 1–6. (The tempting " $\frac{10 - 8}{8} = 0.25$ " happens to give the same number here, but the principled route is time-per-unit, not points, so the definition never drifts.)
Set $n$ = units of work over the horizon. We deliver one unit of clean work per sprint for $6$ sprints, so $n = 6$ units, each with $C_{0} = 1$ . Why this step? $n$ counts the future changes/work items the debt touches — here, six sprints of building on the service.
Apply the master inequality (in sprints, then dollars). Total interest $= n C_{0} i = 6 \times 1 \times 0.25 = 1.5$ sprints. Fix cost $P = 1$ sprint. Compare $P = 1 < 1.5$ ⇒ do the cleanup. In money: interest $= 1.5 \times \$ 20{,}000 = $30{,}000 $v s f i x$ $20{,}000 $; n e t s a v in g$ $10{,}000$.

Verify: consistent units throughout — $i = 0.25$ came straight from the definition (time-per-unit), $n C_{0} i = 1.5$ sprints $= \$ 30{,}000 $, f i x$ = $20{,}000 $, s a v in g$ = $10{,}000$. ✓ See Agile Sprint Planning for reserving that cleanup sprint.

Case H — Exam twist: classify AND decide

The trap: an exam gives you a Fowler quadrant and an ROI decision in one question. They are independent — a well-managed loan can still be worth keeping.

Worked example Ex 8 · cell H

"To hit a launch demo, the team knowingly ships without tests for a rarely-used admin panel, and files a ticket to add them. $C_{0} = 1$ , $i = 0.3$ , $n = 2$ (panel is almost never touched), test-writing cost $P = 3$ . (a) Classify on Fowler's quadrant. (b) Should they pay it down next sprint?"

Forecast: a tracked, planned shortcut on cold code — two separate judgments.

(a) Classify. Chosen on purpose ⇒ Deliberate. Tracked with a ticket + plan ⇒ Prudent. So Deliberate–Prudent — the "healthy" quadrant. Why this step? Classification is about intent and awareness, not about ROI. The ticket is what makes it prudent (see Software Maintainability, Unit Testing).
(b) Decide with the inequality. Interest $= n C_{0} i = 2 \times 1 \times 0.3 = 0.6$ days. Why this step? Classification does not tell you whether to fix — the numbers do.
Compare: $P = 3$ vs $0.6$ . Is $3 < 0.6$ ? No ⇒ do NOT add the tests to cold code; the ticket can stay parked. Why this step? Healthy debt on rarely-touched code is exactly the debt you keep. Classification "good" ≠ "must repay."

Verify: interest $= 0.6$ , $P = 3 > 0.6$ ⇒ keep. The two answers ("Deliberate–Prudent" and "don't repay") are consistent, not contradictory. ✓

Recall Quick self-test across all cells

Which factor being zero always kills a refactor case? ::: Any of $i = 0$ or $n = 0$ (or $C_{0} = 0$ ) — the interest term $n C_{0} i$ collapses to zero, so no positive $P$ can be smaller. In the partial-fix case, what replaces the master inequality? ::: $P < n C_{0} (i_{now} - i_{after})$ — you only "buy back" the reduction in interest. Why does compounding make "do it later" a trap? ::: $i$ grows with each unclean edit, so the interest line curves upward and crosses $P$ sooner — waiting increases the cost you're deferring. Does a Deliberate–Prudent classification mean you should repay? ::: No. Classification measures intent/awareness; the $P < n C_{0} i$ test decides repayment separately. Can $n$ be a fraction? ::: Yes — in practice $n$ is an estimate or expected value (e.g. a 30% chance of one edit ⇒ $n = 0.3$ ); the inequality works for any $n \geq 0$ .

See also: Refactoring, Test Driven Development, Coupling and Cohesion, Continuous Integration.