The importance of simple software

Simple software wins.

It wins because it is easier to think with. It wins because it is easier to maintain. It wins because each new thing built on top of it inherits the clarity, instead of inheriting the mess.

But simple software is rare. Most software accretes complexity the way a house accretes objects: slowly, in tiny increments, each one defensible on its own, none of them coordinated. Six months in, the codebase has thirty toggles, four ways to do the same thing, and a meeting every week to keep track of which one is current. Nobody decided this. It just happened.

Simplicity is not what is left after you remove things. It is what you commit to before you add them.

The product that says no four times out of five is the one that arrives with a clear shape. The product that says yes four times out of five becomes a junk drawer in two quarters. Most software today is a junk drawer with a marketing team.

The pressure goes the wrong way

The pressure inside a team is always toward more. More features ship. More features show up in the press release. More features fill the changelog. The team is rewarded for completion, not for taste. When completion and taste conflict, completion almost always wins, because it is easier to measure.

That is the meta-problem. Simplicity is invisible. Nobody opens an app and says, "I love that this app does only three things." They say, "I love this app." The simplicity is the substrate that makes the love possible, but it does not get credit, because credit is given to things that are easy to point at.

The work, then, is internal. Nobody outside the room is going to congratulate you for the version you didn't ship. Either you build a culture that congratulates itself for it, or the team drifts toward more.

How simple software stays simple

The teams that ship genuinely simple things have one habit in common. They say no, in writing, every week.

They keep a list of features that could be added but were not, and they treat that list as proudly as the list of features that were. They write down the version of the product they didn't build, so they remember what they refused. They review the no-list more often than the to-do list, because the to-do list, left to its own devices, grows monotonically.

That is the operating posture. The other posture — let's just add this one thing — is what every software project that ever got worse converged toward.

Who simple software is for

There is a version of "less, but better" that quietly becomes "less, for the people I think deserve it." Simplicity, used badly, is a velvet rope. The team draws the box smaller; the people on the wrong side of the box are the people who didn't know the conventions, didn't grow up on the right hardware, didn't read the right manuals.

That is paternalism, not simplicity.

Technology touches more people, more hours of more days, than anything else humans have ever built. A small handful of teams decide what billions of people get to use, every day, for the rest of their lives. That kind of power should be exercised with a particular kind of humility — building things that invite people in, not things that demonstrate the builder's taste.

The discipline of saying no should be exercised against features, not against people. Saying no to a feature is saying yes to focus. Saying no to a person — to whoever doesn't speak the language, didn't grow up on a Mac, didn't learn the keystrokes — is saying they were never the customer.

Simple software that is also accessible is much harder to build than simple software that is exclusive. Restricting the feature set is one half of the job. Designing the remaining surface so that someone can walk up to it cold, with no priors, and feel invited — that is the other half. And it is the half that almost never gets credit, because the people who would have given the credit were turned away at the door.

What simple software earns you

Compounding. Each thing you build on top of simple software is faster than it would have been on top of complicated software, by some small amount, multiplied by every future thing. The slope of your work gets steeper. A team that holds the line on simplicity for two years is doing the same work in half the time of a team that didn't — and the work is better, because the surface they're building against is still legible to them.

This is the underrated game. Most of what looks like talent in software is actually accumulated simplicity. The team that ships fast in year five is the team that protected the foundation in year one.

Simple software is hard to build. It is harder to keep. And it is the only configuration that pays back across time.

Less, but better.