The Cost of Simplicity - Why Real Simplicity Is More Expensive Than Complexity

Simplicity looks cheap. One line instead of ten, a small API, a clear flow, few options.

But in large systems, real simplicity is one of the most expensive things to build. Far more expensive than complexity.

Because complexity - simply happens. Simplicity - gets designed, maintained, and fights for its existence.

What Is “Simplicity,” Really?

Simplicity isn’t:

• Less code
• Fewer classes
• Or a short API

Simplicity is a state where:

• Most users do the right thing effortlessly
• Edge cases don’t leak everywhere
• And the system behaves predictably even as it grows

It’s an experience, not a quantitative metric.

Why Is Complexity Cheaper?

Because complexity is the default.

Every new requirement:

• Adds another if
• Another parameter
• Another exception
• Another “just for this case”

No one chose complexity. It just happened.

An Analogy: A Desk vs. One Drawer

Imagine a desk.

Complexity: Every document stays wherever it was randomly placed. Over time - piles, notes, objects, layers.

Simplicity: There’s one drawer. For that to work - you need to:

• Decide what goes in
• What doesn’t
• What gets thrown out

Order requires hard, ongoing decisions. Mess doesn’t.

Why Is Simplicity So Expensive?

Because maintaining simplicity requires:

• Saying no to legitimate features
• Unifying cases instead of handling each one separately
• Absorbing internal cost to save it from the user
• Rewriting instead of adding another layer

All of these are expensive decisions:

• Technologically
• Organizationally
• And sometimes politically too

That’s why simplicity doesn’t survive on its own.

External Simplicity vs. Internal Complexity

In mature systems, simplicity is almost always achieved this way:

the complexity doesn’t disappear - it just gets compressed inward.

• More internal code
• More tests
• More architectural thought

So that the external interface stays quiet, clear, and stable.

It’s a trade: the system pays - so the user doesn’t have to.

An Architectural Thought

If a system is “simple” to extend, add to, and change - it’s probably just not big enough yet.

Real simplicity gets tested when:

• Requirements multiply
• Edge cases multiply
• And pressure increases

And then the question isn’t “is this simple right now?” but “what price are we paying to keep it simple?”

Conclusion

Complexity is the result of motion. Simplicity is the result of choice.

That’s why, in large systems, the most expensive thing you can build - is a system that looks simple.