Reversibility over Prediction

There are two ways to deal with an unknown future. The first is to predict it and align the system with the prediction. The second is not to predict it and to build the system so that it can adapt when the future arrives. The first is tempting because it feels like foresight. The second is superior because it does not depend on having been right.

This document takes a single stance and derives everything from it: reversibility belongs where prediction used to be. You cannot know which requirements will come — so you should not bet on them, but make sure that change stays cheap. That is not a rejection of planning, but a different way of planning: not for a guessed future, but for the ability to cope with any future. It is deliberately framework-neutral; the stance applies regardless of technology.

1. Why prediction fails

Prediction in software architecture means optimizing the system for a particular expected future: this load, those integrations, this growth, these requirements. The problem is not that people predict badly, but that the future of a living system is fundamentally unpredictable. Requirements emerge through use, from a world that changes — and nobody knows the decisive ones at build time.

Anyone who builds for a specific future anyway makes their system brittle against every other one. Every assumption embedded deep in the structure is a bet. If it pays off, you have saved time; if it does not, you have built a structure that stands in the way of the actual need — and that is expensive to change precisely because it sits so deep. Prediction trades a small, certain gain today for a large, uncertain risk tomorrow.

Trade-off. Forgoing prediction means giving up the comfortable appearance of foresight and living with more openness — which feels less decisive.

Cost. Openness toward an unknown future demands more general, more restrained structures, which cost more thought in the moment than one that fits the expected future exactly.

When we decide differently. Where the future is actually fixed — a legal requirement, a contractually fixed volume, an immovable interface — that is not a prediction but a fact, and you may build firmly on it.

2. Reversibility as the alternative

The alternative to prediction is not aimlessness, but reversibility: you make decisions in such a way that you can take them back if they turn out to be wrong. Instead of guessing which future will come, you make sure that no future becomes expensive. The yardstick of good architecture thus shifts from "did we predict correctly?" to "how expensive is it to correct ourselves?"

That is a deeper security than any prediction can offer. A correct prediction only helps in exactly the one future it hit; reversibility helps in every one. It is insurance against the fact that you know little at the start — and at the start, you always know little. A system whose decisions stay reversible is allowed to be wrong without failing because of it.

Diagram: prediction picks one branch and builds on it. Reversibility builds so that every branch stays reachable — it does not need to know which one will come.

Trade-off. Reversibility buys adaptability with additional structure — boundaries and seams that you introduce only to keep your options open.

Cost. This insurance is not free: some seams are never needed, and you have paid for flexibility that does not pay off.

When we decide differently. If a decision is right with high certainty and its reversal is extremely unlikely, you do not build in insurance; a seam against a case that never occurs is itself just complexity.

3. Two kinds of decisions

Reversibility becomes manageable as soon as you distinguish decisions by how reversible they are. Some are doors you can walk through in both directions — if you get them wrong, you turn back, and the mistake was cheap. Others are doors that close behind you — once through, there is no easy way back, and the mistake is expensive. Almost every decision can be assigned to one of these two kinds, and the assignment determines how you handle it.

The common mistake is to treat both the same: to debate the reversible decision as long as the irreversible one, or to make the irreversible one as quickly as the reversible one. Both are wrong. Reversible decisions should be made quickly, because their mistakes cost nothing and hesitation only costs time. Irreversible ones should be made slowly, because their mistakes cost everything and care pays off. The art lies not in always being cautious, but in applying caution where it counts.

Trade-off. Sorting decisions by reversibility costs a moment of classification before every commitment — in exchange for distributing care and speed correctly.

Cost. The classification is not always clear-cut; some decisions look reversible and are not, and you only see that on close inspection.

When we decide differently. For clearly small, obviously reversible decisions, you skip the classification and simply decide quickly; the effort is reserved for the few whose reversibility is unclear or whose impact is large.

4. Which decisions to slow down

The distinction yields a simple rule for pace. You deliberately slow down the few irreversible, consequential decisions: you examine alternatives, gather more knowledge, defer the commitment until the last responsible moment, and record why you decided as you did. Everything else — the many reversible decisions — you make quickly and adjust as you learn more.

Diagram: the same question — reversible? — distributes speed and care. The reversible flows through quickly; the irreversible is deliberately slowed down.

The value of this rule is that it makes care economical. A team that treats every decision with equal thoroughness wastes its thoroughness on the trivial and has none left for what matters. Whoever, by contrast, recognizes the one irreversible decision and gives it full attention while making a hundred reversible ones quickly is both at once: fast and careful.

Trade-off. Making most decisions quickly means living with many small corrections instead of getting each one perfect up front — that looks less tidy, but it is cheaper.

Cost. The rule requires an honest assessment, at every consequential commitment, of how reversible it really is — a judgment call that cannot be delegated.

When we decide differently. In an environment where almost everything is reversible — a young, small system — slowing down is almost entirely unnecessary; the rule only shows its value where irreversible decisions become real.

5. Reversibility in design

Reversibility is not just a stance, but a design property you create concretely. The most effective tool is boundaries: where a part sits behind a clear boundary, it can change without touching the rest — and, if need be, can be replaced without shaking the whole. A decision you place behind a boundary turns from a global one into a local one, and thus from an expensive one into a cheap one.

The second family of tools makes change itself cheap: grow additively instead of rebuilding what exists, so that new things arrive without breaking old ones; run the old and the new side by side for a while, so that you can switch over and switch back; hide a consequential commitment behind an exchangeable layer, so that the choice remains open later. The same discipline that migrates a database in small, reversible steps is reversibility in its purest form — applied to the riskiest change of all.

Finally, reversibility in design includes timing: the last responsible moment. An irreversible commitment that can be deferred without blocking progress gets deferred — not out of indecision, but because every day gained brings knowledge that makes the decision better. The art lies in recognizing the point at which deferring would become more expensive than deciding: until then, openness is a gain; after that, it becomes a blockade. Whoever hits this point decides with the greatest knowledge still available in time.

Trade-off. Boundaries and seams cost additional structure and some awkwardness in the design — in exchange for a later change staying local and cheap.

Cost. Every boundary you draw is itself something you have to understand, operate and maintain; too many boundaries make a system as heavy as the rigidity you wanted to avoid.

When we decide differently. Where a part will certainly never be replaced or changed in isolation, you draw no boundary around it; a seam with no future use is just effort.

6. The cost of reversibility

An honest document about reversibility must name its price as clearly as its benefit — because reversibility can be overdone, and then it becomes exactly the burden it was meant to prevent. Every boundary, every exchangeable layer, every option kept open costs something: structure, comprehensibility, code that someone has to maintain. A system armed against every conceivable change is so complicated that even its present-day task suffers.

This is where reversibility touches its own caricature, premature flexibility. A seam against a case that never occurs is not insurance but wasted complexity — the same trap as premature abstraction, just under another name. The art is therefore not to make everything reversible, but to recognize the few decisions whose reversibility is worth the price and to deliberately commit the rest. Reversibility is "as much as necessary," not "as much as possible."

The line between healthy reversibility and its caricature runs along a single question: is the change you are insuring against likely — or merely conceivable? Building against the likely is prudence; building against the merely conceivable is waste, because everything is conceivable. Whoever insures every possibility insures nothing really, but spreads their resources across cases that never occur. Reversibility thus demands the same judgment as its opposite: recognizing what is likely enough to earn the price — and the courage to deliberately do nothing about the merely conceivable.

Trade-off. Building reversibility selectively rather than everywhere means deliberately leaving some commitments irreversible — you forgo flexibility to keep simplicity.

Cost. This restraint requires a judgment about which change is likely enough to deserve insurance — and that judgment can be wrong.

When we decide differently. Where a future change is not just possible but likely and expensive, you build the seam even if it looks like over-engineering today; likelihood, not mere possibility, justifies the price.

7. When prediction is right after all

Reversibility over prediction is a stance, not a dogma, and it knows its exception. Where the future truly is fixed, building on it is not a bet but the right way to handle a fact. A legal requirement that applies; a contractually fixed volume; an external interface that will not change — on such fixed points you build firmly, and reversibility against them would be effort without return.

The difference lies between prediction and certainty. Prediction is a guess about something unknown; certainty is knowledge about something fixed. The stance of this document is directed against betting on guesses, not against building on certainties. The mistake is treating a guess like a certainty — taking your own expectation for the future. Whoever separates the two cleanly knows where they may build firmly and where they must stay open.

Trade-off. Building firmly on a genuine fixed point buys simplicity at the cost of being tied to that point — as long as it really is fixed, that is a good trade.

Cost. The difficulty lies in recognition: some things look fixed and are not, and a guess wrongly taken for certainty is the most expensive bet of all.

When we decide differently. As soon as a supposed fixed point turns out to be movable — a law that can change, a partner who switches — you treat it as a guess again and build reversibly.

8. Reversibility and decision records

The irreversible decisions you deliberately slow down deserve special treatment: you record them. A short record — what was decided, which assumptions held, which alternatives were examined and why you decided as you did — is not bureaucracy, but the precondition for cleanly revising a decision later. If you do not know what a commitment was based on, you cannot reverse it in good conscience; you can only guess.

This closes the circle back to reversibility. Even an irreversible decision becomes reversible to a degree when a later team understands what it was based on and under which condition it would need to be made again. The record makes visible the assumption the decision hinges on — and when that assumption falls, you know it is time to decide anew. Reversibility thus lives not only in the code, but also in the system's memory.

Trade-off. Recording decisions costs time in the moment and discipline over time — in exchange for a later correction knowing what it builds on.

Cost. A record that nobody maintains or reads is wasted effort; the value only arises if it is actually consulted during the revision.

When we decide differently. You do not record reversible everyday decisions; the record is for the few irreversible, consequential commitments whose later revision is conceivable.

9. Common mistakes

The recurring patterns in which the stance fails — almost all of them variations of treating a guess like a certainty:

• Optimizing the system for one expected future and making it brittle against every other.
• Taking a guess about upcoming requirements for a fact and embedding it deep in the structure.
• Debating reversible decisions endlessly even though their mistakes cost nothing — care in the wrong place.
• Making irreversible decisions quickly and casually because in the moment they look like progress.
• Overdoing reversibility and building a seam against every conceivable change until the system suffocates on its own flexibility.
• Misjudging the reversibility of a decision — considering something retrievable that is not.
• Making irreversible decisions without recording the assumption and rationale, so that a later revision gropes in the dark.
• Mistaking a movable point for a fixed one and building firmly on it.

10. Decision checklist

To be clarified in order before every consequential commitment:

• Prediction or certainty? Am I building on something fixed — or betting on a guess about the future?
• Reversible? Is the decision a two-way door or a one-way door? What does it cost to take it back?
• Right pace? Am I making the reversible decision quickly and the irreversible one slowly — not the other way around?
• Late enough? Is the irreversible commitment made at the last responsible moment, when knowledge is greatest?
• Boundary possible? Can the decision be placed behind a boundary or layer that makes it local and thus cheaper to reverse?
• Proportionate? Is the built-in reversibility worth the price — or am I building flexibility against a case that will not occur?
• Recorded? Are the assumption, alternatives and rationale written down for the irreversible decision?
• Trigger named? Does a later team know under which condition this decision would need to be made again?

Whoever can answer these questions has not predicted the future — they have made themselves independent of getting it right.

FAQ

Isn't reversibility just another word for procrastination? No. Procrastination avoids a decision that is due; reversibility even makes reversible decisions early and quickly, and deliberately keeps only the few irreversible ones open until they can be made with the most knowledge. The difference is the distinction: you selectively slow down the irreversible, not everything.

Does that mean you shouldn't plan at all? On the contrary — it is a way of planning. You do not plan for a guessed future, but for the ability to cope with any future. That often requires more thinking than a bet on one course, not less. What gets planned is adaptability, not the course.

Can't you just build everything reversibly and skip the sorting? No. Building everything reversibly is so expensive and complicated that it destroys the very simplicity that is at stake — the same trap as premature abstraction. Reversibility is "as much as necessary." Its value lies precisely in recognizing the few decisions that deserve the insurance and deliberately committing the rest.

How do I recognize an irreversible decision? By the cost of reversal. Ask: if this turns out to be wrong in a year — how much would have to change to take it back? If the answer affects only one local spot, the decision is reversible; if it affects half the system or external users, it is not. Data formats, public interfaces and deeply anchored structures are typical one-way doors.

What if an irreversible decision has to be made now? Then you make it — but slowly, with alternatives examined, at the last responsible moment, and you record what it is based on. Sometimes a seemingly irreversible decision can also be turned into a reversible one through a boundary or layer; it is worth looking for that before you commit for good.

How does this relate to predicting load and scaling? Scaling, too, is usually prediction, not certainty. Instead of building for a specific load, you keep the scaling decision reversible — clear boundaries, so that later you can scale the part that really needs it. Only where a volume is contractually fixed is it a certainty you may build firmly on.

Further reading

• Software that still runs in ten years — why changeability over the lifetime is the real yardstick; reversibility is its means.
• Why software projects really fail — the flip side: what happens when decisions become irreversible before they are understood.
• Why premature abstraction creates complexity — the line at which reversibility tips over into wasted flexibility.
• Modular monolith vs. microservices and Zero-downtime database migrations — boundaries and reversible steps as applied reversibility.

It is grounded in the Batunet Engineering Method: don't predict the future, keep change cheap — decide the reversible early, the irreversible late and deliberately.

Closing engineering principle

Prediction rewards those who got lucky; reversibility rewards those who were careful. A system built on a guessed future stands or falls with the quality of the guess — and guessing is not an engineering virtue. A system whose most expensive decisions stay reversible until you know enough is allowed to be wrong without failing. That is why reversibility is the more mature answer to an unknown future: it does not demand being right, only being able to correct yourself. And the latter is in your own hands.

You cannot predict the future. You can only build so that you never need to have predicted it — and that is precisely the difference between luck and engineering.