Ockhams Razor

Ockham's Razor

Definition. Given a choice between two designs that perform the same function equally well, prefer the simpler. Simplicity reduces cognitive load, eases maintenance, lowers cost, improves performance, and reduces failure modes. Complexity should be added only when it earns its place by serving a real need. The principle is named for the medieval philosopher William of Ockham, who argued that "entities should not be multiplied beyond necessity" — the simplest explanation that fits the evidence is preferred.

In design, the razor cuts when comparing functionally equivalent options. If two designs serve the user's need equally well, pick the simpler one. The simpler design will be easier to learn, easier to maintain, less expensive to build, less likely to break, and easier to evolve.

The principle is widely cited and widely misapplied. It does not mean "always strip features" or "minimum viable everywhere." It means: don't add complexity that doesn't earn its place. When two equally-good options exist, choose simpler. When a more complex option is genuinely better, choose it; just verify that the complexity is actually paying its way.

Why the razor matters

Complexity has costs that often go uncounted at the moment of decision:

Cognitive cost. Every feature, every option, every visual element costs the user attention and learning. A product with 50 features is harder to learn than one with 10, even if all 50 are individually useful.

Maintenance cost. Every line of code, every component, every dependency needs to be maintained. A simpler system has fewer places to update, fewer interactions to debug, fewer surprises.

Reliability cost. Each component is a potential failure point. A simpler system has fewer components, fewer interactions, fewer edge cases. Reliability tends to improve with simplicity.

Performance cost. Complex systems are harder to make fast. Simpler systems are usually faster by default.

Evolution cost. Adding a new feature to a simple system is easier than adding it to a complex one. Complexity compounds.

Documentation cost. Complex systems need more documentation, which itself becomes a maintenance burden.

These costs are paid continuously, often invisibly. Complexity feels free at the moment of addition; it becomes expensive over time.

When the razor cuts

When comparing two designs that produce the same outcome. The simpler one is preferred.

When evaluating whether to add a feature. Does the feature earn its place? Could the user accomplish the same goal without it? If yes, the absence is simpler.

When pruning an existing product. Features, options, settings that don't serve the user well should be candidates for removal.

When choosing technical architecture. A simpler architecture (fewer services, fewer abstractions, fewer technologies) is easier to maintain.

When picking between visual treatments. A cleaner design that communicates the same information is preferred over an elaborate one.

When the razor doesn't apply

When the more complex option is genuinely better. The razor cuts only when alternatives are equivalent. If the complex option serves users substantially better, choose it.

When simplification destroys necessary capability. A medical interface that simplifies away critical information is too simple. The right level of complexity depends on what the system needs to do.

When the simpler option doesn't actually work. A simple solution that doesn't solve the problem isn't simpler in any meaningful sense — it's just incomplete.

When the complexity is in the underlying problem. Some problems are genuinely complex. Trying to make the solution radically simpler than the problem usually fails.

The razor is a tiebreaker, not a mandate. Its work is to prevent unnecessary complexity, not to force inappropriate simplicity.

Diagnosing accumulated complexity

Products tend to accumulate complexity over time, often invisibly. Symptoms:

Settings that no one understands. A settings panel with dozens of options whose meanings have been forgotten.

Features that no one uses. Features added for some specific need years ago that are now used by 0.1% of users.

Workflows with branches. A flow that has 8 different paths through it, each handling a slightly different case.

Documentation that's longer than the code. A sign that the design has accumulated complexity that's hard to explain.

Onboarding that takes longer. New users need more time to understand the product than they used to.

Engineers afraid to touch certain code. Code so complex that no one understands it; changes are risky.

Many "exception" handlers. A codebase with many special cases for specific situations.

These are all signs that the razor might be useful. Look for things that can be removed, simplified, or consolidated.

Sub-skills in this cluster

• ockhams-feature-pruning — Removing features, options, and complexity that no longer earn their place. The discipline of cutting back what's accumulated.
• ockhams-equivalent-designs — Identifying when two designs are functionally equivalent and applying the razor. The skill of recognizing when simpler is just as good.

Worked examples

Two equivalent designs for a setting

A team is debating two designs for a "default sort order" setting:

Option A: A dropdown with 5 options, each clearly named.

Option B: A wizard that asks the user 3 questions and infers the right sort.

Both produce the same result (the right default sort). Option A is simpler — fewer interactions, less code, less explanation needed. Option B is more elaborate but doesn't produce a better outcome.

The razor cuts: choose A.