A four-engineer team has six weeks to ship a billing feature and proposes four shortcuts to make the date. Three are fine to take. Which one must not be taken and what is the test that separates them?
Show the full answer Hide the answer
The test
Rank shortcuts by who else must change when you reverse them. Three questions, in order:
- Does reversing it require only this team editing its own code? Then it is cheap, whatever it looks like.
- Does it write values into data you keep? Then reversing the code does not reverse the data.
- Does anyone outside the team depend on it? Then reversal needs their calendar, not yours.
A shortcut that fails only question one is debt. A shortcut that fails question two or three is a decision. Elegance does not appear in the test, and neither does how bad the shortcut feels.
Why floats in a ledger fail it
Binary64 cannot represent 0.01 exactly, so every stored amount is already slightly wrong and the error is not recoverable from the stored value. Change the column to a decimal type next quarter and you have converted approximately-wrong numbers into exactly-stored approximately-wrong numbers. The information needed to correct them was never written down.
The arithmetic compounds in the direction that matters most. Sum a million line items and the rounding error accumulates; a reconciliation against a payment provider's own integers then differs by an amount nobody can attribute, and the difference grows monthly. Six months in, a finance close has no correct answer, and the remedy is a reconstruction project from provider statements rather than a migration.
It also fails question three. Invoices, exports and tax filings carry the values outward, so the corrected figures contradict documents already sent.
Why the other options fail as answers
- Skipping integration tests. A recurring cost, paid in slower releases and escaped defects, and fully reversible: write the tests later against the same interfaces. It gets worse the longer you wait, which makes it debt with interest - not a one-way door. Taking it for six weeks with a named date to repay it is a normal trade.
- Hard-coded tax rate. One deploy to fix, and tax-rate changes arrive with statutory notice, so you know the deadline. The thing to check is that the rate is not also persisted on the invoice rows without the rate that was applied - record the rate used alongside each amount and the shortcut stays reversible.
- One deployable instead of three services. This is usually the right call at four engineers rather than a shortcut. Splitting a module later is routine; merging three services back together is the expensive direction, and a six-week deadline is not the moment to guess at boundaries.
When this is the wrong answer
When the amounts are ephemeral. A float in a seven-day analytics cache, a progress estimate, or a display-only rounded total recomputed from an authoritative integer source is fine - nothing durable carries the error and the reversal is a cache flush.
The same test says the inverse too: a shortcut that looks tidy can still fail it. Choosing an identifier scheme, a tenancy boundary or an event schema in week one is a decision, not debt, because other systems will copy it before you get the chance to change your mind.