The field guide · rule 16 of 16
Fix the cause, not just the symptom
Every system has bad days. What counts is a calm account of what happened, and a rule that stops it happening again.
What it means
Every system has incidents. Write a short, calm account: what happened, how you noticed, how you fixed it, and the rule you added so that kind of failure cannot happen again. Fixing only the one case leaves the door open for the next one.
What goes wrong without it
A bug is patched in a hurry, nobody asks why it happened, and a cousin of the same bug comes back a month later.
How I build it
- In one of my systems, a missing exchange rate quietly fell back to a wrong default, and some payouts went out too large. The fix: one part owns the rate, there is no fallback, and if the rate is missing, payouts stop.
- A data reader once kept moving forward while quietly failing to save. It now raises an alarm after a few failed saves, because a hidden error must never look like success.
- Orders that a trading bot had lost track of once stalled it for days. The fix replaces stale orders safely and limits retries.
Ask your team
- Do you write down what happened after each incident?
- Does each fix include a guard against that kind of failure?
- Do the same problems keep coming back?
How a review checks this
A review asks for your last few incidents, and checks whether each fix closed the whole class of problem or only the one case.
Request a reviewThe offer: Architecture review or handover checkCheck your system in one minute