Architecture Decisions — Telling Apart What You Can Undo From What You Cannot

How to separate the design decisions you can cheaply reverse from the ones you can never take back. Measuring reversibility, writing ADRs that record what you gave up, and a template for putting trade-offs into words — from first principles.

You Can Repaint a Wall; You Cannot Remove a Load-Bearing Column

Picture a home renovation. If you dislike the paint, you repaint next week. Moving the kitchen costs a week and a few thousand dollars. But removing a column that holds the building up means redrawing the assumptions behind the entire floor plan — and sometimes it simply cannot be done.

Software design decisions have the same shape. The trouble is that, unlike a house, you cannot see which parts are columns and which are paint. Worse, it has nothing to do with how much work the change looks like. Swapping your logging library touches a lot of files and is still paint. Choosing between a sequential integer and a random string for user IDs is three lines of code and it is a column. Nobody will ever care about the first. The second comes back years later as "we want to merge in the acquired company's users, but the IDs collide."

Architecture is not the craft of drawing tidy boxes and arrows. It is the craft of telling a column from paint, and spending your time only on columns. What junior engineers do is agonize over every decision with the same intensity. What senior engineers do is throw away ninety percent of the decisions in five minutes so they can spend a week on the remaining ten.

The Intuition: A Decision Costs What It Costs to Undo

How heavy a decision is comes down to what you pay when you get it wrong. The key point is that the probability of being wrong and the cost of undoing it are two different things. A decision you often get wrong but can cheaply undo is not worth worrying about — you are better off getting it wrong quickly. A decision you rarely get wrong but that is catastrophic to undo is worth real investigation.

Multiply the two and you get the weight of a decision.

$W$ is a rough measure of how much time the decision deserves, $P_{\text{wrong}}$ is the chance that the choice turns out to have been a mistake, and $C_{\text{undo}}$ is what reversing it would cost then — engineer-months, downtime, and lost trust all included. In words: spend care only where "likely to miss" times "how much the miss hurts" is large.

What this buys you is permission to stop distributing caution evenly. If $C_{\text{undo}}$ is small, $W$ stays small no matter how high $P_{\text{wrong}}$ is — so a reversible decision is faster to try than to debate. And $C_{\text{undo}}$ grows with time. The day after you build something, nobody uses it and undoing is free; the shape of an API that thirty external companies now call is no longer yours alone. The same decision drifts toward irreversible the longer it sits.

The Mechanism: Three Sources of Irreversibility

"Expensive to undo" has exactly three causes. Once you know them you can classify a technology choice you have never seen before.

First: promises that have left your building. Public API field names, URL shapes, webhook payloads, SDK function signatures. These are baked into other people's code, so changing them requires moving other people. Anything you cannot finish through your own effort alone falls on the irreversible side.

Second: accumulated data. The schema is the easy part; what hurts is the meaning you encoded into the data. Suppose you stored an amount column tax-inclusive for three years and someone now needs the pre-tax figure — the history cannot be recovered. Discarded information does not come back. Same logic for timestamps stored without a time zone, addresses normalized until the original spelling was lost, and records you hard-deleted instead of soft-deleting.