Building Things That Last

The average lifespan of enterprise software is about twelve years. That sounds like a long time until you consider that the systems it often replaces are also twelve-year-old pieces of software. We build to be replaced, and we know it.

The rare exception — the piece of software that survives a decade, gets used in ways nobody anticipated, and remains valuable — is worth studying not because it has the right answers, but because it made different bets about what questions would remain constant.

What Doesn’t Change

The systems that age well tend to have been built around things that change slowly: the underlying problem domain, the user’s actual need, the fundamental constraints of the environment. The systems that age poorly tend to have been built around things that change quickly: frameworks, patterns, the aesthetics of the current moment.

This sounds obvious in retrospect. It’s not obvious in the moment, because frameworks and patterns are always presented as solutions to permanent problems. The REST API, the microservice, the event-driven architecture — each was presented, when it arrived, as a permanent advance on previous thinking. Most weren’t. They were better fits for the constraints of their particular moment, and when the constraints changed, the systems built for them became expensive to maintain.

The Epistemic Posture

What I’ve come to think is that durable software is less a technical achievement than an epistemic one. The systems that last longest are built by people who were genuinely uncertain about what the future held — and who structured their systems around that uncertainty rather than trying to optimize for the future they expected.

This has practical implications:

• Keep interfaces narrow. The less surface area you expose, the less you’re committed to maintaining.
• Prefer boring technology. Not because exciting technology is bad, but because boring technology has a track record. You know where its failure modes are.
• Separate the parts that change from the parts that don’t. The business logic often changes slowly. The interface to the business logic changes constantly. Building as if these are the same kind of thing is expensive.
• Write for the person who comes after you. Not in the sense of comments and documentation (though yes, those too), but in the sense of making the why legible — the reasons behind choices that might otherwise look arbitrary.

The Humility Problem

The hardest part of building for durability is that it requires a kind of humility that isn’t rewarded in the short term. The system that will still be running in 2035 doesn’t look as impressive as the system built with the current best practices. It doesn’t use the right frameworks. It looks slightly out of date before it ships.

What it has instead is a tight correspondence between what it does and what the underlying problem actually requires — a resistance to the accumulation of accidental complexity that plagues systems built to impress.

I’ve built things that lasted longer than I expected, and things that didn’t. The difference, in retrospect, was almost always humility about what I actually knew versus what I was assuming. The durable systems were the ones where I held my assumptions loosely and built accordingly. The brittle systems were the ones where I was confident I knew what the future looked like.

I was usually wrong. The systems that outlasted my predictions were the ones designed for that possibility.