The field guide · rule 05 of 16
All or nothing: no half-done changes
A change should happen completely or not at all, never halfway.
What it means
Some changes have several steps. If the system stops in the middle, you are left with a half-done change, which is often worse than no change. Make each change all or nothing. Databases do this with transactions. Files do it by writing a new copy and swapping it in. Releases do it by building the new version beside the old one and switching only when it works.
What goes wrong without it
Money leaves one account, the server restarts, and the money never arrives in the other.
How I build it
- My AI agent system writes each file to a temporary copy and swaps it in, in one step, so a crash never leaves a half-written file.
- In my chain-intelligence service, each database change and the record that it ran are saved together, in one step.
- Space.ke releases are built in a separate folder and checked before the switch. If the site or its back end fails the check, both go back to the last version.
Ask your team
- If the server stops halfway through a payment, what is left behind?
- Can a release be undone in one step?
- Are related database changes saved together, or not at all?
How a review checks this
A review traces each multi-step change and marks every place where a crash could leave it half done.
Request a reviewThe offer: Architecture review or handover checkCheck your system in one minute