Technical debt: interest, not just principal

A family moves in the week before school starts. The back door has swollen, so they shave it with a quick plane cut, knowing it really needs rehanging. Twenty times a day someone shoulders it open. The loft hatch sticks just as badly, but it is opened twice a year, so nobody touches it. A carpenter's day to rehang the back door is repaid in saved shoves within weeks.

In the house	In the code
the quick plane cut before school	a deliberate, prudent shortcut (steps 1, 11)
a shoulder shove on every trip through	interest, paid per change (step 2)
the loft hatch, opened twice a year	rarely touched debt: leave it (step 7)
the carpenter's day	the principal (step 3)
saved shoves covering the carpenter's day	payback (step 8)

Breaks down when: a door costs the same shove every time, while code built on a shortcut makes later changes dearer as more is built on it (step 5).

In real terms: each debt gets an extra cost per change, the changes planned for it, and the days to pay it off.

4.1 ExamHall EXH-3860 → MR !4160: scoring rules in four places

ExamHall's grading worker scores each question type by rules that were copied into four places: the grading worker, the regrade job, the results export and the appeals tool. EXH-3860 is a synthetic pricing of that debt; MR !4160 moves the rules into one table.

EXH-3860 · scoring rules copied into 4 places · a new question type: 1.5 days with the copies, 0.5 day with one rule table
  interest per new type   1.5 − 0.5 = 1.0 day
  roadmap                 3 new types in Q1, 3 in Q2 · interest 3.0 days a quarter
  MR !4160 principal      4 days to move the rules into one table
  paid back               after the 4th new type (Q2) · by the end of Q2: 6.0 days saved, 2.0 net
  timetable importer      ugly, 2 days extra per change, 0 changes planned · interest 0 · left as it is

The interest is the day each new question type costs because four copies must change; the roadmap turns it into days a quarter. Moving the rules into one table costs four days and stops that interest, so it has paid for itself after the fourth new type. Four copies that change together are past the rule of three in pat-over-engineering, so one table is no guess. The timetable importer is just as ugly, but nothing on the roadmap touches it, so its interest is zero and it waits. The pitch to the product manager is those lines: a day per question type, three days a quarter, paid back in Q2. The figures are synthetic; the script replays them and measures no real team.

4.2 Payments ledger: a debt pitched in days

A payments ledger keeps each account code's posting rules as if-branches in its posting service, so every new code is a code change, a review and a deploy. The figures are synthetic.

Ledger account codes · a new account code: 2.5 hours in the posting service, 0.5 hour in a mapping table
  interest per new code   2.5 − 0.5 = 2.0 hours
  plan                    12 new codes a quarter · interest 24 hours a quarter = 3.0 working days (8 h)
  principal               4 days (32 hours) to move the mapping into a table
  paid back               after the 16th new code (Q2) · pitch: 3.0 days a quarter now, 4 days once

The interest is counted in hours, then turned into working days for the pitch: three days a quarter now, four days once, paid back in Q2. The hours per code come from the team's own debt lines.