Exercises — Technical debt — types, managing

(a) = bug — the behaviour is wrong. (b) = technical debt — the behaviour is correct, but the code is costly to change/understand/extend. Debt is about changeability, not correctness. This is the single most tested distinction in the topic.

(i) = Principal ($P$). (ii) = Interest (rate $i$ applied over $n$ changes ⇒ total $n{C}_{0}i$). Money-metaphor mnemonic: you borrow (shortcut), you pay interest until you repay the principal.

Axis 1: Deliberate vs Inadvertent (did you choose the debt?). Axis 2: Reckless vs Prudent (did you plan/track it?). The only "healthy" cell is Deliberate + Prudent.

• Total interest $=n{C}_{0}i=8\times 3\times 0.4=9.6$ days. Why: that's the whole extra time the mess will steal across all 8 changes.
• Compare: $P=12$ vs $9.6$. Since $12>9.6$, the rule $P<n{C}_{0}i$ fails.
• Decision: do NOT refactor. The one-time fix (12) costs more than the total interest you'd ever avoid (9.6). Net loss from refactoring $\approx 2.4$ days.

• Total interest $=20\times 3\times 0.4=24$ days.
• $P=12<24$ ⇒ rule holds ⇒ refactor now. Net saving $=24-12=12$ days.
• Lesson: the only number that changed was $n$. High-traffic code almost always earns its refactor because total interest scales linearly with how often you touch it.

Deliberate (chosen on purpose) + Prudent (tracked, with a plan) = Deliberate–Prudent = the healthy cell. The ticket is exactly what upgrades it from reckless to prudent.

Break-even is where fixing and keeping tie: $P=n{C}_{0}i$. Why rearrange? We want the answer as a number of changes, so we isolate $n$ — divide both sides by $C_{0}i$ (allowed because $C_{0}i>0$), which cancels $C_{0}i$ on the right and leaves $n$ alone: $n_{\star }=\frac{P}{C_{0}i}=\frac{6}{2\times 0.5}=\frac{6}{1}=6.$ The picture below shows the two costs as straight lines meeting at $n_{\star }$ — look at it first, then read the decision.

Reading the figure: the red sloped line is total interest $n{C}_{0}i$ — it starts at the origin and climbs by $C_{0}i=1$ day per change. The black horizontal line is the principal $P=6$ — flat, because you pay it once. They cross at the black dot $n_{\star }=6$. Left of the dot the red line sits below $P$ (keep the debt); right of the dot it rises above $P$ (repay). Axes: horizontal = $n$ (number of future changes), vertical = cost in days. Decision: for $n>6$ ⇒ refactor; for $n<6$ ⇒ leave it; at $n=6$ exactly (the tie) ⇒ keep the debt (net saving is zero, so the tie breaks toward not spending the principal).

• Flat line = principal $P$. You pay it once, so it does not depend on $n$ ⇒ horizontal. (Black in the figure.)
• Sloped line = total interest $n{C}_{0}i$. It grows by $C_{0}i$ for every extra change ⇒ a straight line through the origin with slope $C_{0}i$. (Red accent in the figure — the key object.)
• They cross at $n_{\star }=P/(C_{0}i)$. Left of the crossing the sloped (interest) line is below $P$ → carrying debt is cheaper → keep it. Right of the crossing interest overtakes $P$ → repay. On the crossing they are equal → keep (tie rule).

$\text{Debt ratio}=\frac{\text{remediation cost}}{\text{development cost}}=\frac{40}{200}=0.2=20\%.$ Meaning: it would take an extra 20% of the effort already invested just to clean the existing shortcuts — a tracking number to watch over time (rising ratio = accumulating debt).

Use the net saving quantity: $\text{net saving}=n{C}_{0}i-P$ (total interest avoided minus the one-time fix). Fund only where it is positive.

• A: total interest $=12\times 2\times 0.5=12$; net saving $=12-6=6$ days.
• B: total interest $=5\times 1\times 0.8=4$; net saving $=4-5=-1$ day.
• B loses money (net negative) — do not fund it. Fund A, saving 6 days. A beats B by $6-(-1)=7$ days of net value.
• Insight: high $n$ (traffic) on Item A dominates. Prioritise the high-traffic debt, matching the parent's rule "fix debt in code you change often first."

• Reserved points $=0.20\times 20=4$ points/sprint for debt.
• Concrete example over 3 sprints. Say the debt backlog is 12 points. With the reserve, each sprint spends 4 on debt: sprint 1 → 8 left, sprint 2 → 4 left, sprint 3 → 0 left — cleared in 3 sprints, guaranteed, because the 4 points are booked before features compete for them. Under "pay later," features expand to fill all 20 points every sprint (they always feel urgent), so 0 debt points get spent and the backlog grows.
• The figure makes the two policies visible side by side:

Reading the figure: each bar is one sprint's 20 points. The red slice is the 4 reserved debt points; the black slice is feature work. Under "reserve 20%" (left group) the red slice appears every sprint and the debt-remaining line (annotated) marches 12 → 8 → 4 → 0. Under "pay later" (right group) the red slice is absent — every bar is all-black feature work — and debt never falls. The visual lesson: a booked slot gets used; an unbooked intention does not.

• Advantage stated plainly: reserving makes repayment scheduled, so it happens; "later" never arrives because features always feel more urgent (the debt-spiral). See Agile Sprint Planning for where this reservation lives, and Refactoring for how the 4 points get spent.

• Fixing an item costs $P$ and saves at most $n{C}_{0}i$ of total interest.
• Net saving of fixing $=n{C}_{0}i-P$. This is negative whenever $P>n{C}_{0}i$, and zero at the tie $P=n{C}_{0}i$.
• So for any item with $P>n{C}_{0}i$ — typically cold code where $n$ is small (recall the $n=0$ edge case: total interest is exactly $0$, so fixing always loses) — spending $P$ destroys value. "Zero debt" forces you to fix those too, so it loses money.
• Exact condition to KEEP debt: $P\ge n{C}_{0}i$ (equivalently $n\le P/(C_{0}i)$). Note the "$\ge$" includes the tie — at exact equality you keep, matching the boundary rule. This defines prudent debt: consciously left because the fix isn't worth it. Optimal debt level = fix everything with $P<n{C}_{0}i$, keep the rest.
• Links: keeping/leaving is a call about Software Maintainability; the "keep it clean where it's hot" spirit is the Boy Scout Rule fed by Continuous Integration and Unit Testing (tests make repayment safe).

• Before: $n_{\star }=P/(C_{0}i)=6/(2\times 0.5)=6$ changes.
• After ($i=1.0$): $n_{\star }=6/(2\times 1.0)=6/2=3$ changes.
• The break-even dropped from 6 to 3 (halved, since $n_{\star }\propto 1/i$ and $i$ doubled). As the rate rises, far fewer future changes are needed to justify a fix — worsening code smells make refactoring more urgent, not less. Rising $i$ shrinks the "keep it" zone. This is the quantitative face of the "debt spiral."

Compute net saving $=n{C}_{0}i-P$ for each:

• X: $10\times 2\times 0.5-6=10-6=4$.
• Y: $8\times 3\times 0.4-5=9.6-5=4.6$.
• Z: $4\times 1\times 0.5-4=2-4=-2$ → reject (loses money).
• Rank by net saving: Y (4.6) > X (4) > Z (reject).
• Budget check: fund Y (5 days) then X (6 days) = 11 days, exactly the budget. Total net saving $=4.6+4=8.6$ days. Z is left as prudent debt.
• This is the whole management loop in one problem: Visible (listed) → Quantify (net saving) → Prioritise (ranked) → Pay-down (fund Y, X) → Prevent (leave Z tracked). See Coupling and Cohesion and Test Driven Development for reducing the rate $i$ at the source so future backlogs shrink.

$n_{\star }=P/(C_{0}i)$ — refactor when $n>n_{\star }$, keep the debt when $n\le n_{\star }$ (the tie keeps).

By net saving $=n{C}_{0}i-P$ (highest first), rejecting any with negative net; then fill the budget.

$i$ and total interest? $i$ is a per-change fraction (slowdown per change); total interest $n{C}_{0}i$ is the lump sum of days across all $n$ changes.

$i$ doubles, what happens to break-even $n_{\star }$? It halves ($n_{\star }=P/(C_{0}i)$), so refactoring becomes justified after fewer changes.

$n=0$ or $i=0$? Total interest becomes $0$, so $P<0$ is always false ⇒ never refactor — carrying the debt is free.

$P=n{C}_{0}i$, do you refactor? No — keep the debt. Net saving is zero, so the tie breaks toward not spending the principal.

remediation cost ÷ development cost (e.g. $40/200=20\%$).