Every senior engineer eventually learns the same painful lesson: the most expensive line of code is not the one that fails, but the one you cannot walk back. A database chosen in a weekend sprint quietly dictates your data model for five years. A vendor SDK wired into thirty services becomes a hostage negotiation. Businesses are waking up to the same reality, and a sharp analysis of the premium on reversibility published by MyLiberla argues that the smartest companies now optimize for the ability to change course before they optimize for scale — a principle that maps almost perfectly onto how we should be making technical decisions. If your architecture review only asks "will this scale?", you are asking the second question first.
One-Way Doors and Two-Way Doors
The clearest mental model here comes from Jeff Bezos, who in his 2015 letter to Amazon shareholders split all decisions into two types. Type 1 decisions are one-way doors: consequential, irreversible, deserving of slow deliberation and heavyweight process. Type 2 decisions are two-way doors: if you walk through and dislike what you see, you walk back out. His warning was that growing organizations start applying Type 1 ceremony to Type 2 choices — and the result is slowness, risk aversion, and "diminished invention."
Engineering teams commit the opposite sin just as often. We treat one-way doors as two-way doors. We adopt a proprietary queue "just for now." We let a schema leak into six consuming services "temporarily." We hardcode a region, a currency, a tenant assumption. None of these felt like commitments on the day they shipped. All of them were.
The discipline, then, is not "avoid big decisions." It is classify the door before you walk through it, and spend your engineering effort converting one-way doors into two-way doors wherever the conversion is cheap.
Reversibility Is an Architectural Property You Can Build
Reversibility is not a vibe; it is a set of concrete mechanisms you can put in place this quarter. The teams that recover fastest from bad bets tend to rely on the same small toolkit:
- Feature flags with kill switches. Every risky behavioral change ships dark, ramps gradually, and can be reverted in seconds without a deploy. The flag is the undo button.
- Interfaces at the blast radius. Wrap third-party services, databases, and payment providers behind thin adapters you own. You are not predicting a migration — you are pricing the option to make one.
- Expand–migrate–contract schema changes. Never rename or drop in one step. Add the new column, dual-write, backfill, cut reads over, then remove the old path. Every stage is individually revertible.
- Explicit stop rules for big projects. Before a rewrite or platform bet begins, write down what evidence would justify pausing or killing it. A project without stop rules is capital trapped in a story.
- Sacrificial layers. Accept that some code exists to be thrown away, and structure it so the throwing away is cheap.
That last idea has a formal name. Martin Fowler calls it sacrificial architecture — the deliberate practice of building a system while expecting to discard it once you have learned what you actually need, the way eBay and Google knowingly outgrew and replaced their early designs. The insight is liberating: the goal was never to write immortal code. The goal is to keep the cost of change low enough that being wrong is survivable.
The Economics Underneath the Engineering
Why does this matter more now than it did in 2019? Because the tolerance for expensive mistakes has collapsed. In the zero-interest-rate era, an over-committed architecture could be papered over with headcount: hire another platform team, absorb the cloud bill, brute-force the migration. Today, engineering organizations are smaller, budgets are scrutinized line by line, and a two-year untangling project is a career-limiting proposal. Irreversibility used to be an inconvenience; now it is unpriced risk sitting on your technical balance sheet.
This reframes what "senior" means. Junior engineers are evaluated on whether their solutions work. Senior engineers should be evaluated on how gracefully their solutions can be changed — by people who were not in the room, years later, under conditions nobody predicted. Optionality is a deliverable. It just never shows up in the sprint demo.
A Practical Checklist for Your Next Design Review
Try adding three questions to your architecture review template and watch how the conversation shifts. First: which door is this? Force the room to say out loud whether the decision is reversible, and at what cost. Second: what would have to be true for us to unwind this in six months? If the honest answer is "a full rewrite," you have found a one-way door wearing a two-way door's costume. Third: what is the cheapest experiment that turns this bet into a learning? Often a week behind a feature flag answers a question the team was about to spend a quarter debating.
None of this is an argument for timidity. Companies and codebases still need bold bets — new products, new platforms, occasionally even the dreaded rewrite. The argument is for honesty about which commitments deserve to become permanent. Build your systems so that being wrong is cheap, and you will find you can afford to be ambitious far more often. The undo button is not a safety blanket. It is a competitive advantage.
Top comments (0)