Technical Debt Is a Loan
When is the fast, ugly version the correct engineering decision?
The idea
A shortcut borrows time now and repays it with interest as every later change becomes slower.
In the real world
A hardcoded value ships in an afternoon and costs a week the first time it must vary.
Going deeper
The metaphor is useful because it has a rate and a term. Interest is paid per subsequent change to that code, so debt in a rarely touched corner is nearly free while the same shortcut in a hot path compounds every sprint.
It also means debt can be written off. Code that gets deleted repays nothing, which is why shortcuts in throwaway validation work are often correct engineering rather than laziness. The decision worth making explicitly is which kind you are taking: a deliberate loan against a known future date, or an accidental one nobody has priced.
Where it stops applying
The metaphor breaks down where the shortcut causes correctness or security problems rather than slowness. That is not debt with an interest rate; it is a defect, and it should be treated as one.
Why it matters
It reframes shortcuts as a financing decision, with a rate and a repayment date, rather than as sloppiness.
Try this today
Name one shortcut you are carrying and what event will force you to repay it.
Test yourself
Two teams take the same shortcut. One is validating whether anyone wants the feature; the other is building the billing system. Why is it a reasonable decision for one and not the other?
Show the answer
The interest is paid per future change, and the loan is written off entirely if the code is deleted. Throwaway validation code may never be changed again, so the debt costs nothing; billing will be modified for years, so the same shortcut compounds.
Learn this in the feed Answering from memory, then again days later, is what makes it stick.