Conceptual Integrity

There is a particular kind of bad system that is hard to describe but immediately recognisable. Not because it is broken; it works, mostly. But because there is no underlying logic you can learn. Every feature is a special case. The naming that holds in one place doesn’t hold in the adjacent one. You can’t predict what you haven’t seen. You navigate by memorising, not by understanding.

Frederick Brooks named this in 1975. The name has stuck.

I’ve watched it happen in teams I’ve worked with. It rarely looks like carelessness. The first version has clear rules; you can feel the coherence. Then the team doubles. A second team builds on top. A third adds a layer. Each team is competent. Each decision is defensible. But nobody’s job was to hold the overall shape of what was being built, and by the time that became visible, it was structural. What comes out the other end isn’t what was designed. It’s what accumulated.

Brooks called what’s missing conceptual integrity¹: “the most important consideration in system design,” he wrote, ahead of performance, ahead of feature completeness. The claim sounds extravagant until you sit with what it means. A system that has it holds together in a way you can learn and extend. You encounter something new and you can reason about where it fits. You understand it the way you understand a language with regular grammar: not by remembering every word, but by having a model of how it works.

The question is how you get it. The answer surprised me when I first read the argument: it has nothing to do with writing clean code, or review discipline, or documentation. It has to do with who controls what the user sees.

Architecture and implementation are different jobs, and treating them as the same is where most teams go wrong.² The architect’s job is to specify the user-visible surface: the interface, the naming, the consistency of behaviours, the shape of error conditions. What the system does and what it doesn’t. Implementation can be parallelised. Architectural decisions can be distributed too, but not independently of one another. Without a mechanism for maintaining coherence, the system eventually loses the very thing you are trying to preserve. Someone has to own the design, and their ownership has to be real, which means they have to be able to say no.

“If a system is to have conceptual integrity, someone must control the concepts,” Brooks wrote. “That is an aristocracy that needs no apology.”³

The aristocracy remark always prompts a wince. It sounds authoritarian. But the structural point is separate from the political one. Democratic contribution doesn’t produce bad ideas. It produces too many good ideas, with no authority to settle the conflicts between them. The result isn’t a bad system; it’s an incoherent one. Nobody was wrong. Nobody was careless. There was just no one whose job it was to say “that doesn’t fit” and have that answer mean something.

The obvious risk runs the other way. Concentrated authority can preserve the wrong design just as effectively as the right one. A coherent system is not the same as a good system. The architect can reject a new idea because it doesn’t fit, while the real problem is that the existing design has outlived its usefulness. Design authority therefore requires more than the power to say no. It needs a genuine mechanism for being challenged, and the judgement to recognise when the concepts themselves need reconsidering, not just the contribution.

The most instructive cases aren’t hypothetical.

Linux kernel governance is more instructive than it first appears. The model isn’t that Linus Torvalds personally reviews every contribution; the kernel uses a hierarchy of subsystem maintainers, each with genuine authority over their domain.⁴ What the hierarchy preserves is Brooks’ insight in a different form: design authority is distributed, but it is never left undefined. Someone at every level can say yes or no, and the chain ends somewhere. That is what makes coherence possible at that scale: not a single architect enforcing every decision, but a structure in which nobody can contribute without passing through a node that holds real design authority.

Guido van Rossum held a version of the same role in Python for nearly three decades. In July 2018, exhausted after the PEP 572 controversy, he stepped down: “I don’t ever want to have to fight so hard for a PEP and find that so many people despise my decisions.”⁵ The Python Steering Council replaced him: five elected members with formal authority to accept or reject PEPs, delegate decisions, and resolve disputes. Python shifted from personal design authority to institutional design authority. What the transition reveals isn’t failure; it reveals that design authority is separable from any individual. The question the Steering Council has to answer, which Guido answered by instinct across three decades, is whether an institution can hold a design sensibility with the same consistency that one person can.

Stripe is the clearest positive example I know of in a commercial API. Many core resources follow consistent conventions: prefixed identifier, object type, created timestamp, livemode boolean, metadata field. An engineer who knows one Stripe resource can reason about any other without reading the documentation first. That doesn’t happen by accident. Stripe has written publicly about the deliberate effort required to maintain consistent patterns as the API grew: proposed changes go through documentation requirements and cross-team review before acceptance.⁶ Someone has the job of maintaining coherence against contributions from many teams. The review process is what makes architectural authority real.

The Windows API tells the other story. Raymond Chen has been documenting it since 2003, and his blog reads as forensic archaeology: thirty years of individually reasonable decisions made by many teams, each time with backward compatibility as the constraint that prevented any rationalisation of the surface.⁷ The API is not incoherent because the engineers who built it were careless. Whether the root cause is the absence of unified design authority, or the inescapable weight of backward compatibility obligations, is a question Chen’s writing raises without settling. What it demonstrates is the endpoint: a surface built by accumulation rather than design, which you navigate not by understanding how it works but by remembering where things happen to be.

The version I’ve encountered most often isn’t a famous project. It’s a product that started with a small group of engineers who shared a mental model and grew into multiple teams that didn’t. Somewhere in that growth, it stopped having a person whose answer to “does this belong here?” was treated as final. The product kept shipping. The coherence kept eroding. Nobody made a bad decision. The design authority was just never formally assigned, and by the time that gap was obvious, filling it meant overruling work that was already done.

The honest objection is about scale. Brooks was writing about systems built in one organisation, in an era when the largest projects had hundreds of contributors. His proposed mechanism, the chief programmer team,⁸ was small-group thinking. Whether the principle survives at much larger scale is a real question, not a rhetorical one.

Rust’s RFC process is the most serious attempt to answer it I’ve seen. Every significant language change goes through an RFC reviewed by a subteam with genuine authority to accept or reject. The Final Comment Period is ten days: a structured decision window after which the subteam accepts, rejects, or postpones the RFC, though it can be reset if substantive new objections arise before it closes.⁹ The subteams are not advisory. They hold the design authority. What the process preserves isn’t the single architect; it’s the concentration of decision authority in a small group with a real mandate and the actual power to enforce it.

Microservices sit at a different position. Each service can have high internal integrity even when the system as a whole does not. Service boundaries can establish different kinds of coherence at different levels; internal design need not mirror the public interface. But cross-boundary coherence doesn’t emerge on its own. Someone has to own the contracts, the shared domain models, the consistency of how services present themselves to each other and to users. Microservices don’t eliminate the need for design authority at the system level; they make it an explicit organisational responsibility. If nobody holds it, the familiar pattern reasserts itself: individually coherent services, accumulated into an incoherent whole.

Most engineering cultures choose accumulation over omission. Features are progress. The question “does this fit?” rarely gets the same airtime as “does this work?” or “can we build it by Thursday?” Brooks’ counter-claim is blunt: a system that omits features but reflects one coherent set of ideas is better than one that includes many good but independent and uncoordinated ones.¹⁰

The engineers adding features in good faith are not the problem. The problem is a structure that has no one whose job it is to ask whether the new thing fits the existing whole, and whose answer, if it is no, is treated as a decision rather than an opinion.

That is what the aristocracy means. Not that one person is better than everyone else. That someone has to hold the design, and that their holding of it has to mean something. And that means, sometimes, telling a team that built something good that it doesn’t belong here. That is the part that doesn’t show up in the theory.