Reversible vs Irreversible Decisions
Renaming an internal function costs a minute to undo; a public API, a database schema, a partition key and a cloud architecture cost progressively more — some of them almost everything. Spend decision effort in proportion to the cost of reversing, and make the expensive ones as late and as small as you can.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
Every decision gets the same meeting — how do you tell which ones deserve it, and which ones you should just make and move on?
The team has spent a week deciding on a naming convention for internal modules and an afternoon choosing the shape of the public order API. You have a feeling the effort is upside down and no way to say why: both were "architecture decisions" and both had a meeting.
Treat decisions as equal. Everything gets a discussion, a document and a sign-off, because being careful is a virtue and it is hard to argue for being less careful about anything.
The uniform process spends its attention on the loud decisions rather than the expensive ones. Naming is loud (everyone has an opinion) and free to reverse; the partition key is quiet (one person understands it) and nearly impossible to reverse, and it gets the shorter meeting.
- The uniform process spends its attention on the loud decisions rather than the expensive ones. Naming is loud (everyone has an opinion) and free to reverse; the partition key is quiet (one person understands it) and nearly impossible to reverse, and it gets the shorter meeting.
- Because every decision is heavy, decisions are avoided — the public API ships with whatever shape the first implementation had, undecided by anyone, and that undecided shape is now the hardest thing in the system to change.
- The week on naming feels like rigour. It produced a document and consensus, and nothing about the store's ability to change was improved by it, because the rename would have cost a minute either way.
- When the irreversible decision turns out wrong, the process is blamed for not having been thorough enough, and next quarter every decision gets a longer meeting.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Before deciding anything, ask what it would cost to reverse — in time, in coordination, in data migrated, in external parties who would have to change. That cost, not the loudness of the debate, is how much decision effort the choice deserves. A minute to reverse: decide now, alone, and note it. A migration and a deprecation window to reverse: a design, a review, and a written record. Effectively irreversible: an experiment first, the smallest possible commitment, and a deliberate delay until the evidence exists.
- Notice what makes a decision irreversible, because it is rarely the code. It is the number of parties who depend on it (a public API has clients you do not control), the volume of state shaped by it (a schema over a large table; a partition key over everything), and the surface it touches (a cloud architecture threads through every deployment and every bill).
- Make expensive decisions cheaper to reverse before making them: put a boundary around the thing (an interface over the storage choice), keep the state small while the decision is provisional, and version what external parties see. A decision that would have been irreversible is often only expensive once it is behind a seam.
- Make them later. An irreversible decision made before the evidence exists is a bet placed at the worst odds; the reversible choices made in the meantime — a modular monolith that can be split, a schema that can migrate — are how the evidence gets bought (Deciding Under Uncertainty).
Five decisions, sorted by what it costs to undo them
The decision device below is not "which option to pick"; it is "how much process does this decision get", with the reversal cost as the criterion. Each option names the tier, when a decision falls in it, and what the tier costs — because giving a decision less process is also a trade.
What would it cost to reverse this — and therefore how much effort does deciding it deserve?
when Reversal is a local change with tool support and no one outside the team notices.
cost Some reversible decisions will be wrong and reversed; consistency may drift without a convention meeting — which is the price of not having spent a week on one.
when Reversal is a migration whose cost is currently low and growing with data.
cost A day of design on something that might have been fine by default; the record has to be kept or the review was theatre.
when Reversal requires parties you do not control to change; a version turns a break into a schedule.
cost Versioning is complexity and a support burden; the first version ships slower than an unversioned one would.
when Reversal would move most of the state or every deployment; there is no evidence yet of the access pattern or the load.
cost A reversible substitute stays in place longer and may become load-bearing; the seam is a ledger entry; the spike costs days before any commitment is made.
How the tiering fails
The table names the ways decision-effort allocation goes wrong in practice. Each row is a real pattern; the response is a question rather than a rule, because the tier of any given decision is a judgment about reversal cost, and reversal cost can be mis-estimated in both directions.
| Trigger | Symptom | Cause | Response |
|---|---|---|---|
| "We can change it later" said of a schema over the largest table | A migration nobody will run; the schema becomes permanent by neglect | Reversal cost estimated from the code change, not from the data | Write the reversal line including the data: "to reverse we would migrate N rows with downtime of…" — then re-tier |
| A naming convention gets a week of meetings | Consensus, a document, and no change in the store's ability to change | Loudness mistaken for stakes | Ask what it costs to reverse; if the answer is a search and replace, one person decides today |
| The provider decision is delayed for a quarter "until we have evidence" | Nothing deploys; the reversible substitute (a laptop) is the production environment | The evidence needed was never named, so it never arrived | Name the evidence, get it with a spike, commit small; a delayed decision needs a trigger |
| An interface over the storage layer that every module bypasses | A "reversible" storage choice that would take a rewrite to reverse | The seam exists on paper only | Either make the seam real (one place that touches storage) or re-tier the decision as irreversible and give it the process |
In what order to make the store's decisions
Reversal cost also suggests an order: make the cheap decisions immediately, make the ones whose cost is growing early, and make the ones that need evidence after the evidence. One order for the store, and an alternative.
- 1Names, module layout, internal conventions
because Reversible in minutes; decide now, alone, and stop discussing.
- 2Orders and products schema, versioned migrations from the start
because Reversal cost grows with every row, so the careful decision is cheapest today; migrations keep it a schedule rather than an event.
- 3Public API shape, with a version number in the URL or header from the first release
because External clients make reversal expensive; the version is the seam that keeps it possible.
- 4Deployment: one region, managed database, the least provider-specific thing that works
because The cloud decision must be made to ship at all; making it small and seamed keeps it expensive rather than impossible.
- 5Sharding and partition keys: not yet
because Effectively irreversible and with no evidence of the access pattern; the unsharded store is the reversible substitute until a measured bottleneck names the key.
How to do it
Most important first.
- For each pending decision write one line: "to reverse this we would have to …". Sort by that line. The order is the order of effort (The Cost of Change in Design gives the vocabulary).
- Anything reversible in under an hour: decide now, by whoever is closest to it, and write one line in the journal so it is not re-argued.
- Anything reversible only with a migration or a deprecation: a short design, one reviewer, a record with the alternatives and the revisit condition (The Decision Journal).
- Anything effectively irreversible: name the evidence you would want before committing, get it with a spike or a slice (Spikes), and put a seam around the decision so that "effectively" gets an escape hatch.
- Look at where the meetings actually went last month. If the long ones were about reversible things, the allocation is upside down, and the fix is a shorter meeting, not a longer one.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- Rename an internal function in the checkout module: reversible in a minute, with the compiler's help. Decide alone, no record beyond the commit. The week spent on module naming conventions belongs in this tier; the convention can be changed with a search and replace, and its value is consistency, not correctness.
- The shape of the public order API — the fields a merchant's integration reads: reversible only with a versioned endpoint, a deprecation window, and every client updating. Deserves a design, a review, a written record — and a version number from day one, so that the next change is a new version rather than a break (Interfaces Emerge From Boundaries).
- The orders table schema: reversible with a migration, which is cheap while the table is small and expensive once it is not. Decide with care, but decide early — the cost of reversing grows with the data, so the decision is cheaper to revisit now than in a year. The partition key for order storage, if the store ever shards: effectively irreversible, because every row's location depends on it and moving them means moving everything. Do not choose it until there is evidence of the access pattern; keep the store unsharded — a reversible choice — until then.
- The cloud architecture — which provider, which managed services, how the network is laid out: threads through every deployment and every bill, and reversing it is a migration project. Make it as late as the first real deployment allows, make it small (one region, managed database, the least provider-specific thing that works), and put the provider-specific pieces behind interfaces so the decision is expensive rather than impossible.
How you know it worked
What now exists that did not before, and what question you can now ask.
- Every pending decision has a "to reverse this we would have to…" line, and the meetings are sized by it.
- Reversible decisions are being made in minutes by one person and recorded in one line, and nobody has re-argued one this month.
- The irreversible decisions have an experiment scheduled before them and a seam around them.
- At least one big decision has been deliberately not made yet, with a stated reason and a stated trigger.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?What would it cost to reverse this — in time, in data, in parties who would have to change?
- ?Is the cost of reversing growing while I wait, or is the evidence I need arriving while I wait — and which is faster?
- ?What seam would make this decision expensive rather than impossible to undo?
- ?Which decision am I giving the long meeting to, and is it the one with the highest reversal cost?
What can go wrong
- Everything is declared reversible. "We can always change it later" is said of the schema over the largest table, and later arrives with the migration nobody wants to run. The reversal cost has to be written down honestly, including the data.
- Everything is declared irreversible. Fear turns every choice into a committee and the store never ships; the tiering exists to free most decisions, not to slow all of them.
- Delaying an irreversible decision forever. "We do not have evidence yet" becomes a way of never choosing a provider; the move says delay until the evidence exists, and says what the evidence is, and goes and gets it.
- Seams that are never used. An interface over the storage choice that every module bypasses is a reversible-looking decision that is not; the seam has to be real or the tier is wrong.
- Tiering decisions by reversal cost means some wrong reversible decisions get made quickly and have to be reversed; that is the intended trade, and it still costs the reversal.
- Seams and versioning that make decisions reversible are complexity — an interface over the store, a version in the API — and each one is a ledger entry that has to be justified by a decision that might actually be reversed.
- Delaying an irreversible decision keeps a reversible substitute in place longer, and the substitute can become load-bearing: the unsharded store that was "until we have evidence" is the store.
- "Reversible means unimportant." A reversible decision can still be worth thinking about; it just does not need the same process, because being wrong is recoverable. The tiering allocates effort, not respect.
- "Make irreversible decisions as late as possible, always." As late as the evidence allows — and the schema example shows a case where the reversal cost grows with time, so waiting makes it more irreversible, not less. The question is which is moving faster: the evidence or the cost.
- "A public API is irreversible." It is expensive to reverse, and versioning turns expense into a schedule. The genuinely irreversible decisions are the ones with no seam and a great deal of state — which is why partition keys are the classic example (Reversible and Irreversible Decisions in Design covers the design-side mechanics).
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALSizing decision effort by reversal cost applies to any engineering choice; the tiers are the same whether the system is a store, a compiler or a pipeline, and only the examples of "irreversible" change.
- STAGE-SPECIFICOn a greenfield store almost everything is reversible because there is no data and no client; the move is to notice which decisions are *about to become* irreversible as data and clients arrive, and to spend the effort just before that. In an existing system with large tables and external clients the tiers are already fixed and the move is mostly about not re-litigating the cheap ones.
- ILLUSTRATIVEThe week on naming, the afternoon on the API and the specific tiering of the store's decisions are invented; a store with one client of its API and a tiny table would tier the same decisions differently.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The Cloud & DevOps domains carry the mechanics of the deployment decision; this lesson only says how much of the meeting it deserves and when.