Building Systems That Endure

Enduring is not the same as not breaking. A system that endures is one that can still be modified by people who did not build it, under conditions nobody anticipated, without every change requiring nerve.

The forces that erode that property are not adversarial. They are ordinary, predictable and they arrive for everyone: people change jobs, vendors change products, volume grows. Each attacks a different part of the system, and it is worth examining them separately before saying what they have in common.

Turnover attacks whatever exists only in someone's head

When someone leaves, the code stays. What leaves is the model of the code: why that queue is that size, which two modules cannot be reordered, which exception is genuinely impossible and which is merely rare. What survives is whatever was externalised — into names, into boundaries, into two lines of text beside the decision.

The observable symptom is the latency between someone joining and making their first safe change unaided. That latency is the most honest measure of how much of the system exists outside people. And there is a derived rule that holds for any team: every constraint held up by discipline is a constraint that leaves with the person who held it. If the only thing preventing a dangerous call is the habit of not making it, the system does not have that constraint — it had a person.

Vendor change attacks undeclared coupling

Replacing a vendor is the stress test of a boundary. The cost of the replacement is not proportional to the vendor's importance; it is proportional to how much of the vendor's shape has leaked into your model. And the leak happens through quiet paths: their identifiers stored as keys in your tables, their vocabulary adopted into your domain, their error semantics scattered through your control flow, their typical latency assumed in the design of your interface.

The asymmetry here is specific and brutal. At first integration, keeping a translation layer costs an interface and some naming discipline. Afterwards, the same layer costs a data migration, because by then the leak is no longer in the code: it is in accumulated state. Code gets rewritten. History gets reconciled, and reconciliation is the kind of work that consumes a schedule while producing nothing anyone can see.

A boundary is cheap while it is still a decision. Afterwards, it is a migration.

Volume growth attacks whatever used to be adequate

Volume rarely breaks correctness. It breaks assumptions about time, and the first effect is usually operational rather than technical. The process that could be re-run by hand no longer can. The report that took a minute takes the whole night and therefore starts running once a week. The manual review that covered everything starts covering part of it.

That last one is the most important and the least noticed: growth quietly converts complete processes into sampled ones. It is a change of control that nobody approved, that appears in no record, and that is discovered only when something passes through precisely the part that stopped being looked at. No alarm fires, because the system is still doing what it always did — only now across a fraction of what exists.

Why all of this is cheap early and expensive later

The central observation of this note is that the cost curve for these properties is not linear. It is convex, for three reasons that compound:

1. 01Adding the property later means applying it to state that already exists. The code change is small; reconciling the history is not, and that is what consumes the timeline.
2. 02Later, the property has to be installed while the system is running. Every change now carries migration risk that the design-time version simply did not have.
3. 03Later, it has to be negotiated with whoever already depends on the current behaviour — including behaviour that was never intended, but became observable and therefore became a contract in fact.

The third reason is the one that surprises experienced teams. A system with real use does not only have the interface it documented; it has every behaviour anyone outside was able to observe and started relying on. Correcting one of those later stops being a correction and becomes a breaking change, with notice, a transition period, and migration work done by third parties who asked for none of it.

What is cheap at design time

It is worth being concrete about the actual size of these decisions, because the word architecture implies a weight they do not carry. Naming a boundary costs a conversation and a short document. Writing down why a threshold holds its value costs one sentence, written while the reason is still obvious to the person writing it. Making state queryable costs deciding where it lives before it is scattered. Making an operation idempotent costs an identifier carried from the origin. Keeping a translation at a vendor's edge costs an interface. None of them is sophisticated, and all of them are hard to add a year later.

Almost everything that makes a system endure is cheap for exactly as long as it is still reversible.

There is an uncomfortable consequence in this. The decisions that most determine a system's working life are taken in the week it matters least, by the people with the least information, under pressure to show something running. There is no elegant organisational fix for that inversion. There is a dull one: treat this short list as part of what delivering means, rather than as quality to be added when there is slack — because there never is.

We publish this as a research note rather than as a method. It is the frame we design against today: three ordinary forces, a small set of properties that resist them, and a cost asymmetry that explains why so few teams apply those properties at the moment they are cheap. If practice shows us that one of these pieces is wrong, we will correct it in public, here.