Ockhams Equivalent Designs

Ockham's Razor — equivalent designs

The razor cuts when alternatives are functionally equivalent. The skill is recognizing when alternatives actually are equivalent — versus when a more complex alternative serves a real need that the simpler one doesn't.

Designers and engineers often defend complexity by imagining benefits the complex solution provides. Sometimes those benefits are real; sometimes they're rationalization. The discipline is honest evaluation of whether the complexity earns its place.

Defining functional equivalence

Two designs are functionally equivalent when they produce the same outcome for users. Specifically:

Same goal achieved. The user can accomplish what they're trying to accomplish.

Same quality of outcome. The result is equally good (correct, complete, accurate).

Same cost to user. The user pays roughly the same in time, attention, learning.

Same edge case handling. Both work for the cases users actually encounter.

Same downstream effects. Both leave the system in the same state for subsequent interactions.

If these are equal, the designs are equivalent for the user, and the razor cuts toward simpler.

When designs that look equivalent aren't

Designs may look equivalent on the surface but actually differ in important ways:

Edge case behavior. One design handles unusual cases gracefully; the other fails. The behavior in the typical case is the same; the long tail differs.

Performance. One design is fast at small scale; the other scales better at large scale. Both work today; the difference matters tomorrow.

Error recovery. One design recovers from failures elegantly; the other doesn't. Most of the time, neither fails; in the failure cases, they differ sharply.

Discoverability. Two designs achieve the same task, but one is more discoverable. Users find one and not the other.

Accessibility. Two designs work for typical users; one fails for users with disabilities.

Internationalization. Two designs work in English; one fails in non-English contexts.

Future flexibility. Two designs do the same thing today; one is easier to evolve.

When evaluating equivalence, check these dimensions, not just the happy path.

When complexity actually earns its place

A more complex design earns its place when it:

Solves a real problem the simpler doesn't. Not a hypothetical problem; an actual user pain point with evidence.

Serves an important audience the simpler doesn't. Even if the audience is small, if it's strategically important, the complexity may be justified.

Enables future capabilities. Architectural complexity that supports planned future work, not speculative future work.

Improves reliability or performance materially. Not in theory; in measurement.

Reduces other complexity. Sometimes adding one component eliminates several others. The net change is simplification.

If none of these apply, the complexity doesn't earn its place.

Evaluating equivalence honestly

Engineers and designers tend to defend their preferred designs. Honest equivalence evaluation requires:

Defining "the user's goal" specifically. Vague goals make any solution look reasonable. Precise goals make tradeoffs visible.

Listing the actual differences. What does design A do that B doesn't? What does B do that A doesn't? Be specific.

Quantifying the differences. Not "A is faster" — "A handles 1000 req/sec, B handles 5000." Numbers force honesty.

Identifying who pays for the differences. Often complexity benefits some users (or the team) and costs others. Be explicit.

Time-shifting the comparison. Today, the simpler design may be sufficient. In two years, the more complex one may be necessary. Make the time horizon explicit.

Worked examples

Two API designs that look equivalent

Option A: A single endpoint that takes a complex JSON body specifying everything.

Option B: Multiple endpoints, each with simpler parameters.

At first they look equivalent — both expose the same functionality. But:

• Option A is harder to document (the complex body has many fields).
• Option B has more endpoints to maintain.
• Option A has more validation logic for the body.
• Option B is easier for clients to understand piecemeal.
• Option A allows transactional behavior (one call); Option B doesn't.

If transactional behavior matters, A wins. If documentation and approachability matter more, B wins. They're not equivalent; pick based on what matters.

Two feature implementations that are equivalent

Option A: A wizard with 3 steps to configure a new resource.

Option B: A single page with the same fields shown all at once.

Both produce the same configured resource. The user experience differs (wizard vs. single page) but the outcome is the same.

For a complex configuration with many interdependent decisions, the wizard helps the user; A is preferred. For a simple configuration with few fields, the single page is faster; B is preferred.

If the configuration is genuinely simple, A's complexity doesn't earn its place. The razor cuts toward B.