Conceptual Integrity

A system should reflect one coherent set of design ideas, even at the cost of some features.

“I will contend that conceptual integrity is the most important consideration in system design.”
— Fred Brooks, The Mythical Man-Month

A system that follows one design reads as a whole; many good but uncoordinated ideas do not.

To an executive

A product built on one clear idea is easier to explain, support and extend. Piling on features from many directions raises the cost of every later change.

To an engineer

Keep the design coherent: new features should reuse existing concepts, not add a second way of doing the same thing. Leave out good ideas that do not fit.

The idea

Brooks argued it is better for a system to omit some anomalous features and improvements, but reflect one set of design ideas, than to contain many good but uncoordinated ideas.

He compared it to cathedrals built over generations: the coherent ones followed a unifying plan. Conceptual integrity requires design to come from one mind, or a small number of agreeing minds. Brooks separated architecture, the design users see, from implementation, and argued that a small group should own the first while many people build the second.

Why it works

Coherence makes a system learnable. When the same ideas recur everywhere, knowing one part tells you how the others work. Users and developers spend less effort on surprises.

Each exception has a cost. A feature that follows its own conventions must be learnt, documented and maintained separately. A few of these are tolerable; dozens make the whole system hard to reason about.

Small design groups can stay consistent. Coordination costs grow with the number of designers. Keeping the core design in few hands is the practical way to keep it in one shape.

Where it applies

Platforms and internal developer tooling, where many teams contribute and conventions diverge quickly.
Public APIs, where every inconsistency becomes a permanent burden on consumers.
Large programmes with several teams, where each team's local choices can fragment the whole.
Domain models, where two meanings for one term break shared understanding.

How to apply

Name the core concepts and a small set of guiding principles, and write them down where everyone can find them.
Give a small group ownership of those concepts, with the authority to say no.
Prefer one way of doing things across a platform: one authentication pattern, one configuration format, one error model.
Check new features against the concepts in design reviews, and drop or reshape those that do not fit.
Automate what you can, for example with linters or fitness functions that enforce the conventions.

Example scenario

An internal developer platform let every team contribute its own conventions. Within two years it had three authentication patterns and four configuration formats, and new teams needed weeks to work out which to use.

A small design group agreed one pattern for each, published them with examples, and migrated the old variants over several releases. New features were reviewed against the agreed concepts before they were accepted. Onboarding fell from weeks to days.

Questions to ask

Could a new engineer predict how an unfamiliar part of this system works from the parts they know?
Does this new feature fit our core concepts, or does it introduce a second way of doing the same thing?
What are we willing to leave out to keep the design coherent?

When not to use it

Early exploration, when you do not yet know which ideas are right and trying several is the point.
Loosely coupled systems owned by independent teams, where internal consistency matters less than stable contracts between them.

How it misleads you

Using integrity to centralise every decision in one architect. The goal is coherence of ideas, not concentration of power. A design group that is out of touch with the teams building on it will produce a coherent system that nobody wants.