The field guide · free to read
16 rules for systems people trust
These are the rules I use to build software that handles money, data and AI. Each one takes about two minutes to read, in plain English, and ends with three questions to ask your own team.
- 01Keep each fact in one placeDecide where each important fact lives, and let everything else read it from there.
- 02Check everything that comes inTreat anything from outside as possibly wrong, and check it the moment it arrives.
- 03Decide what happens when things breakWhen part of a system fails, choose whether it stops or carries on, by asking what a wrong answer would cost.
- 04Make actions safe to repeatConnections drop and people press twice. An action that runs twice should have the same effect as running once.
- 05All or nothing: no half-done changesA change should happen completely or not at all, never halfway.
- 06Store money in whole numbers, and make the books balanceNever store money in a way that rounds. Use whole cents, and write down the rule that must always hold.
- 07Give each part only the power it needsKeep keys out of the code, and design so that one broken part cannot do much damage.
- 08Prove who is askingEvery request should prove who sent it, and that it was not changed or sent again.
- 09Several simple guards beat one clever wallNo single check is perfect, so stack simple, separate guards. When one misses, the next one catches it.
- 10Expect other services to failRetry what is safe, pause what keeps failing, keep a second source, and never blindly resend money.
- 11On a blockchain, wait until it is finalThe newest blocks can be replaced. Wait for confirmations, count each transaction once, and refuse old requests.
- 12Let only one worker move the moneyWhen several copies of a program run at once, decide which jobs may run in one place only.
- 13Keep AI on a budget and on the factsTreat AI like any paid service that is sometimes wrong: cap the cost, give it checked facts, check its answers, and keep a person in charge.
- 14Let tests decide when work is doneAgree what "correct" means as tests before you build, and for money, test the rule itself.
- 15Ship only what was checked, and watch it runRelease exactly what was reviewed, check it after every release, keep a way back, and hear about problems before your users do.
- 16Fix the cause, not just the symptomEvery system has bad days. What counts is a calm account of what happened, and a rule that stops it happening again.
What to do next
Answer five questions about your own system and see which rule to look at first. Or ask the assistant about any rule.
Check your system in one minuteAsk a questionRequest a review