Occam's Razor

Among designs or explanations that fit the facts, prefer the one with the fewest assumptions.

When two designs both meet the requirements, the one with fewer parts and assumptions should win.

To an executive

Every extra component adds cost, delay and things that can break. Asking each addition to justify itself keeps the organisation faster and cheaper to run.

To an engineer

When diagnosing, check the plain explanations first, such as a bad config push. When designing, make each new moving part justify itself against a stated requirement.

The idea

Occam's razor is named after William of Ockham, the 14th-century English philosopher. In its common form it says: do not multiply entities beyond necessity. Among explanations that fit the facts equally well, prefer the one that assumes least.

The principle is not that the simplest answer is always right. It is that unnecessary complexity should carry the burden of proof.

Architects use it in two places. In diagnosis, the outage is more likely a bad configuration push than a rare hardware fault. In design, every additional moving part must justify its existence against a stated requirement.

Why it works

Each assumption is a chance to be wrong. An explanation or design that depends on fewer things being true is less likely to fail on one of them.

Complexity has running costs. Every component, hop and abstraction must be built, secured, monitored, upgraded and understood by the next team. Those costs arrive whether or not the component was needed.

Common causes are common. In incidents, recent changes and familiar failure modes explain most problems. Checking them first finds the answer faster.

Where it applies

Design reviews, especially of proposals that bring in several new technologies at once.
Incident diagnosis, when the team is drawn to an exotic theory before ruling out the obvious.
Technology selection, where a single well-understood tool might meet the need.
Integration design, where each extra hop adds latency and a new place to fail.

How to apply

Write down the real requirements first, including scale, consistency and regulatory needs.
Ask each component which requirement it serves. Anything that serves none is a candidate for removal.
Compare options on the requirements, then on assumptions. If two fit equally well, choose the one with fewer parts and fewer things that must go right.
In incidents, rule out the mundane first: recent deployments, configuration changes, expired certificates, full disks.

Example scenario

A proposed design for an internal compliance form included an event bus, a workflow engine and a CQRS read model. The form would receive around fifty submissions a day, and the requirements were to store them, notify a reviewer and keep an audit trail.

The reviewer asked which requirement each component served. None needed asynchronous processing or a separate read model. A single transactional service with one table, an audit log and an email notification met every stated requirement. The team kept a clean module boundary so a workflow engine could be added later if volumes or rules changed.

Questions to ask

What is the simplest design that meets the real requirements?
Which component could we remove without losing a requirement?
Is there a mundane explanation we have not ruled out yet?

When not to use it

Genuinely complex domains, where the simple model does not fit the facts; then the razor does not apply, because the options are not equal.
Known future requirements that are firm and near; designing for them now may be cheaper than retrofitting.

How it misleads you

The razor can be used to oversimplify. "Simplest" must still fit all the facts, including regulatory, scale and failure requirements. A design that looks simple because it ignores a requirement is not simpler; it is incomplete. Simplicity also differs by viewpoint: fewer components can mean more complex code inside each one.