Nature's Razor: Why Simplicity Always Wins

Nature is lazy. Light, water and evolution all find the cheapest route that works, and the products and codebases that last do the same. It’s the most practical rule I know, and nobody ever taught it to me in a classroom.

Nature takes the cheap route

Physics calls it the principle of least action. Of every path a system could take, it follows the one where a quantity called action is smallest. Light crossing from air into water bends at the exact angle that gets it there in the least time. Water runs downhill. A thrown ball follows the same arc every time, because every other arc costs more.

You can derive most of classical mechanics and optics from that one idea.

Evolution runs on a similar budget. Every extra structure costs energy to build and to keep, so it only survives if it pays for itself. A stick insect doesn’t carry camouflage and armour and speed. It looks like a stick, and that’s enough.

Gall’s Law

In 1975 John Gall, a paediatrician who wrote about why systems fail, put the same idea in a form engineers can use:

“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”

Gall doesn’t say complexity is bad. He says you can’t design working complexity in one step. You can only grow it from a simple system that already works.

What this means for products

Most of the failed products I’ve watched started complex. They tried to solve ten problems at once and had feature lists that read like CVs. Then they died.

The ones that won started with one thing:

• Google launched as a search box. No portal, no directory.
• Instagram was photo filters and a feed. Stories, Reels and shopping came years later.
• Slack was chat rooms you could search. Not an everything app, just chat that didn’t suck.

All three are complex now. None of them started that way. They worked first, then they grew.

Every feature costs your users something: one more thing to learn, one more option to skip past. It costs your team too, because someone has to keep it working. The simplest product that solves the problem wins because it asks the least of the people using it.

What this means for code

In software I haven’t seen an exception.

The systems I’d happily maintain started small. They had clear boundaries and did one job well. They grew when real use demanded it, and each addition had to fit the shape of the original design.

The systems I dread started with microservices before they had users. They had abstraction layers over their abstraction layers. They were built to scale for load that never came, and they solved problems the business didn’t have yet.

Those systems don’t evolve. They set hard. Every change breaks something else, and every new developer needs a PhD to follow the architecture. Eventually someone proposes a rewrite, which is an admission that the team built complexity before it built something simple that worked.

Using it as a razor

A razor is a rule for cutting away bad options. This one cuts like this:

• A new feature: does it solve a real problem in the least complex way? Or are we adding it because we can?
• A new system: what’s the simplest version that could work, and can we ship that first?
• A design that feels complicated: take the feeling seriously. It usually means you’re designing complexity instead of growing it.
• A “comprehensive solution”: be wary. Comprehensive usually means designed complex from day one. Ask what simple system you could start with instead.

The hard part is discipline

Understanding this is easy. Following it is not.

It’s tempting to design for scale on day one, to add flexibility you might need later, to fix the next problem while you’re in there. It’s tempting to look sophisticated.

Don’t. Build the simplest thing that could work and ship it. Let real use show you where the complexity belongs. Then add it reluctantly, and only when living without it hurts more than the complexity will.

Simple is usually harder to build than complex, because you have to decide what to leave out. It’s also what survives. Nature has been selecting for it for billions of years.

Be lazy like the universe.