On restraint.

We meet a familiar pattern in our discovery work. A system has accumulated for ten or fifteen years. Each year, a thoughtful engineer added something — a new layer, a new abstraction, a new optionality. The additions were almost all individually defensible. Looked at in sequence, they tell the story of an organisation that took its work seriously.

And yet the system is now the thing slowing the organisation down. The cost of change has overtaken the cost of doing nothing. The architecture is no longer architectural; it is sedimentary. The original drawing has been overwritten by a hundred good intentions.

What happened?

The cleverness tax

The most common failure of long-lived software is not a bad decision. It is a series of cleverer-than-necessary ones. Every clever abstraction introduces a small tax — a moment of indirection, a question to be re-answered, a mental model to be carried — that compounds quietly across years and across people.

The engineer who introduced the abstraction had a reason. Often a good one. But the reason was held in their head, while the abstraction was held in the codebase. Within eighteen months the reason has decayed and the abstraction remains, now functioning as a small obstacle to whoever inherits it.

We have learned to ask, before adding any layer of indirection: what is the strongest version of the argument for not adding it? If the strongest version sounds reasonable — if the project would survive without the abstraction — we err on the side of restraint. It is almost always the cheaper decision.

“

The strongest abstractions are the ones the next engineer recognises immediately as useful. The weakest are the ones they ask about and then politely route around.

”

Restraint is not minimalism

Restraint is sometimes confused with minimalism, but they are not the same thing. Minimalism is an aesthetic; it is about visual or structural simplicity for its own sake. Restraint is something else — it is the discipline of deferred decision-making. Of holding back from the answer until the question is well-formed.

A restrained system can be large. The legal code of a serious country is large. What makes it restrained is that every part of it has been considered, named, and ratified. There is no part of it that is there because someone added it once and nobody has removed it.

The same is true in software. A restrained codebase is one in which every choice has been re-chosen. Anything that has slipped in without consideration has been quietly removed. The result is not always smaller; it is, however, almost always more comprehensible.

The skill of subtraction

Subtraction is harder than addition, and not in the obvious ways. The technical work is sometimes trivial — a deleted file, a removed configuration, an unbuilt feature. The hard part is institutional. Every removal has a constituency, even if the constituency is just one engineer who once cared.

We do this work in three stages. First, we name the candidates for subtraction — concretely, in writing, with rationale. Second, we negotiate the removals with the people who built them. This is the longest stage. Third, we act, all at once, in a single review window. The cumulative effect is usually visible within a quarter.

The output is rarely impressive in isolation. Twelve services merged into four. A configuration file with seventy options reduced to nine. Two thousand lines of dead abstraction removed. These are not the kinds of artefacts that win awards. They are the kinds that quietly make the next year of engineering easier for everyone.

What restraint protects

Restraint protects three things, in roughly this order:

• Comprehensibility. A system you can hold in your head is one you can change confidently. A system that exceeds your working memory is one you change with prayer.
• Optionality. Every premature commitment forecloses a future direction. Restraint preserves the ability to make better decisions later, when you know more.
• Trust. Engineers trust systems that have been edited recently in either direction. A codebase that only ever grows is a codebase nobody is willing to read.

The first is the most often-cited and the least urgent. The third is the least often-cited and the most urgent. Restraint is, in part, a trust-building exercise: it is how you signal to your colleagues that the system is being maintained by people who are still paying attention.

A note on velocity

The most common objection to restraint is that it slows you down. We have not found this to be true in any engagement that lasted longer than a year. In short engagements it is sometimes the case; the cost of the deferred decision shows up later, in someone else's quarter.

In long engagements, restrained codebases are noticeably faster to evolve, because the cost of any individual change is bounded by the comprehensibility of the surrounding code. The compound interest is very large.

We have come to think of restraint as a velocity strategy that compounds across years. It looks slow in the first quarter and disproportionately fast in the fifth.

Closing

If we had to pick a single discipline to insist on across our engagements — and we have been asked, more than once — it would be this one. Not architecture, not testing, not observability, although we believe in all three. The discipline that makes those three possible is restraint. The willingness to hold back, to remove, to leave room.

Most of the systems we admire are restrained. Most of the systems that frustrate us are not. The asymmetry is striking; the conclusion, we think, is unavoidable.