The cost of a mistake
where you can trust, and where you cannot
What it is
Checking everything equally carefully is impossible, and unnecessary. The question is what to decide by: where to skim and where to read line by line.
The common answer — "by how hard the task is" — is wrong. The right criterion is different: what the mistake costs if it happens. And that cost is made of two things: how easy it is to roll back, and how quickly you would notice.
How to work it out
Reversibility
How simple it is to put things back.
| Easy to roll back | Hard to roll back |
|---|---|
| a code change under git | a migration that altered the data |
| a new function nobody calls yet | messages already sent to users |
| a local experiment | deleted files |
| a change covered by tests | a published release people have downloaded |
Git makes almost anything involving code reversible — which is why it gets an article of its own (5.1). What is irreversible is what has left the repository: data, mail, money, publications.
Visibility
How quickly the mistake announces itself.
| You'll notice at once | You might not notice for months |
|---|---|
| it won't start | wrong numbers in a report |
| it crashes with an error | records lost during an import |
| the button does nothing | the wrong time zone |
| tests go red | a leak that only shows under load |
The right column is the dangerous one. A mistake that crashes the program is honest: it reports itself immediately. A mistake that quietly corrupts data surfaces once everything is already corrupted.
Together
| Notice at once | Might not notice | |
|---|---|---|
| Easy to roll back | skim: run it and look | carefully: read the logic |
| Hard to roll back | carefully: read the diff | line by line + plan + tests |
The bottom-right corner is migrations, mailings, money and other people's data. There you need all of it: a plan (article 3.10), a mini-spec (3.15), tests (3.9) and a read of the diff (2.13). The top-left is what you can simply run.
What to tell the AI
The assessment can be handed to the AI, and it does it reasonably well:
Before you start: what in this task is irreversible,
and what could break without being noticed? Briefly.For anything that changes data there is a separate question:
Does this change modify existing data? If so, how do I roll
it back if it turns out to be wrong?If there is no answer to the second question, the task cannot be started: the way back comes first, the change second.
Make the migration reversible: keep the old file instead of
deleting it. Rename rather than delete.What to look for
Irreversible work done without a rehearsal. Migrations, bulk edits,
mailings — all of these are first run against a copy. A no-write mode
(--dry-run) that only prints what it was about to do costs one sentence to
ask for and saves you regularly.
Deleting instead of renaming. rm and DROP are irreversible, renaming
is not. It is the cheapest way to make an operation reversible.
No way to notice. If a change has no test, no log and no visible effect, you will be the last to learn that it was wrong.
Trust out of habit. Five good changes in a row do not make the sixth safe. The level of checking is set by the task, not by the previous run of luck.
Cheat sheet
Checking is tuned to the cost of a mistake, not to difficulty.
Cost = reversibility × visibility.
The invisible is the dangerous one: it surfaces once everything is spoiled.
Bottom-right corner (irreversible + invisible) — plan, spec, tests, diff.
No way to roll back — don't start; invent the way back first.
Rename instead of deleting.