Decisions That Aged Badly

The decisions I most regret were not careless.

They were defensible at the time. Reviewed. Discussed. Approved. Made by capable people with the information they had. The reasoning was sound. The cost arrived years later, often after the people involved had moved on.

That gap — between the moment of choice and the moment of consequence — is what makes "decisions that aged badly" a different category from "decisions that were wrong."

A wrong decision is easy to point to. You can name the missing analysis, the ignored warning, the sloppy reasoning. You can fairly assign blame. Sometimes you should.

A decision that aged badly is harder to find fault with. The analysis was correct given what was known. The context simply changed. The system moved past the assumptions the decision rested on. What was once a reasonable trade became a load-bearing constraint nobody chose.

These two failure modes feel similar in retrospect. They are not the same thing.

Regret without blame

Most engineering hindsight collapses them. Either everything in the past was a mistake — which is unfair and useless. Or nothing was — which prevents any learning at all.

The honest middle is harder to hold: a decision can be defensible at the time and still age badly.

The useful posture toward this category is regret without blame. Regret, because the system would be better if it had gone differently. Without blame, because the people who made it were paying attention. They simply could not see the ten years that came after.

There is a real risk in this posture, worth naming. "Regret without blame" can degrade into evasion. It can become the language a team uses to avoid examining actual misjudgments — analyses that were wrong on their own terms, warnings that were available and ignored. The discipline is to keep the categories separate. Some decisions were wrong. Some aged badly. Some were both. Treating every bad outcome as a victim of changed context is its own failure of judgment.

A few recurring patterns

Premature abstractions. The shape of the problem was not yet clear. Someone wrote a generic interface for the cases they could anticipate. The cases that actually arrived were not those. The abstraction now obscures more than it reveals, but it is widely depended on, so it stays.

Optionality preserved just in case. A configuration flag, a plugin point, a strategy interface for one strategy. Each was nearly free at the moment it was added. Cumulatively they form the bulk of the system's surface area. Most are still unused. Removing them is a quarter of work.

Tooling chosen for early productivity. The framework that made the first six months fast. The build system that fit the original architecture. The infrastructure decision that suited the founding team's expertise. None of these were wrong. All of them eventually became things future maintainers had to work around rather than with.

Coupling between things that did not need to know each other. The shared database two services briefly used together. The library that grew to import from the application. The deploy pipeline that assumed one team's release cadence. Each coupling was a small saving at the time. Each is now a constraint.

Best practices imported without context. The pattern that worked at a previous company. The architecture style that fit a different problem at a different scale. The decision was anchored in authority rather than fit. The cost shows up only when the team has moved past the conditions that made the practice useful elsewhere.

Decisions made under deadline that became permanent. The temporary table. The hardcoded value. The "we'll fix this next sprint." There is no next sprint. The shortcut becomes the shape.

The shared property is reversibility

The common factor across these is not effort or skill. It is reversibility.

Each one reduced the cost of the present by spending the future's optionality. Each made the system easier to write and harder to change. The asymmetry was invisible at the time because the future maintainers were not in the room.

Reversibility is itself contextual. What is reversible for a small team can be effectively permanent for a large one, because the cost of coordination scales faster than the cost of the change. A two-line config swap in a startup is a multi-quarter migration in a public company. The honest test is not "could this be undone in principle" but "is the team that would have to undo it likely to be able to."

This is why the strongest single filter on long-lived decisions is not "is this correct." It is "is this reversible by the people who will inherit it."

A reversible decision can be wrong and still survive. The team adjusts as understanding improves. An irreversible decision must be defended against every change in context that comes later, usually by people who do not know why it was made.

Most decisions that aged badly were locally optimal and globally irreversible.

What changes with this lens

Looking back, the change I would make is not a particular technical choice. It is to commit later and lighter. To treat decisions as hypotheses. To assume I will be partly wrong, and to build so that being wrong is survivable.

The decisions that aged best in the systems I have known were rarely the cleverest. They were the smallest commitments that addressed the actual problem. Smaller surfaces. Fewer dependencies. Shorter assumptions. Things that could be undone in an afternoon.

That is not a guarantee against aging. Nothing is. It is the best available defense.

Regret without blame ends in a single lesson. The judgment is not "I should have known." It is "I should have made it cheaper to be wrong."

That posture is the one I try to carry into the next decision.