On Building Software Systems That Last
Longevity in software is not an accident. It is the result of specific architectural decisions made early — and a set of habits that resist the entropy of…
Systems that survive multiple generations of engineers and multiple technology cycles share a set of architectural properties that are detectable before the fact. This essay identifies those properties and examines the engineering habits — and organizational habits — that produce or destroy them.
Every system I have inherited had the same archaeology: a thin layer of coherent intent on top, then deeper strata of expedient decisions, each one made when time was short and the context was slightly different from what the next layer assumed.
This is not a failure of engineering discipline. It is the natural geology of software. The question is not how to prevent accumulation — it is how to build foundations that support it without buckling.
The Invariant Layer
Every durable system I have studied or built has at its center a small core of things that almost never change: the data model, the core abstractions, the primary invariants. Not the implementation — the concepts. These are usually expressible in a paragraph, sometimes in a diagram.
The mistake most teams make is conflating this invariant layer with the implementation layer above it. When the two are coupled, changing anything requires changing everything, and the system calcifies. When they are separated by a clear boundary, the implementation can evolve freely while the conceptual integrity persists.
The Protocol Instinct
Teams that build lasting systems tend to have a protocol instinct. Before they ask "how do we implement X?" they ask "what is the interface contract for X?" They treat the contract as the primary artifact and the implementation as a consequence.
This instinct shows up everywhere in durable systems: explicit versioning strategies, well-defined failure modes, human-readable operational contracts. It slows early development by approximately 20% and accelerates every subsequent change indefinitely.
Durability Is Not Elegance
There is a trap in the craft tradition of software: conflating durability with elegance. Elegant code is often locally optimized for the current understanding of the problem. Durable code is often slightly over-specified for the current need — explicit where it could be implicit, verbose where it could be terse — because those redundancies carry load when the system grows in ways nobody anticipated.
The systems I trust are not the ones that impressed me when I first read them. They are the ones that were still coherent, still modifiable, still honest about their own structure when I returned to them two years later.
Build for return visits.