Practice / The mechanism

Who carries the complexity

Every feature has an irreducible amount of complexity. The only question is who ends up holding it: the product team, the engineering team, or the person using the software.

Tesler’s Law#

Larry Tesler formulated this at Xerox PARC in the mid-1980s, and his operational version is blunt: if a million users each waste a minute a day on complexity an engineer could have removed in a week, you’re penalizing the user to make the engineer’s job easier.

Complexity is conserved. It doesn’t disappear when you decline to handle it. It settles with whoever has the least room to say no, which is usually the person with the least context and the least time.

The consensus is near-total#

Joel Spolsky, in 2000: it’s the height of arrogance for a designer to inflict a choice on the user because the designer couldn’t think hard enough to decide which option was better. Jeff Atwood, drawing on Nielsen, on what it costs to leave design decisions to the person using the software. Jason Fried and DHH: your app should take sides.

Marty Cagan draws the same line between teams that exist to solve customer problems and teams that ship what stakeholders request. Kathy Sierra named the cost: cognitive leaks, anything that drains a person’s limited attention on something unrelated to their actual goal.

Defaults are the experience#

Most people never change a default. Nielsen documented the Cornell search-ordering study: when results were secretly reordered, the top position still took 34 percent of clicks. People followed position, not quality.

For the large majority the default is the entire product. Whatever value a new field or view or setting ships with is what most users will have forever. Optimize the default before building the customization.

Opinions over options#

A toggle is usually evidence that the team couldn’t decide. Add one when you have evidence that real users need both behaviors and that neither is clearly correct. Otherwise commit.

Linear’s framing is that flexible software lets everyone invent their own workflows, which becomes chaos as teams scale, and that your tools shouldn’t make you their designer and maintainer. Intercom’s is shorter: opinionated by default, flexible under the hood.

Convention over configuration#

Infer from structure. Don’t require declaration. This is the Rails doctrine, and Vercel applied the same idea to deployment: framework, build settings and routing detected from the shape of the project, no config file.

Applied to a feature, the first question is what can be inferred from what the customer already has. An account with facilities, teams and staff already contains enough signal to produce a working default without asking anyone anything.

Existing state is sacred#

People have sunk costs in their current setup. Windows 8 required seventeen years of muscle memory to be rebuilt and peaked around seven percent share. Figma shipped Auto Layout with migration code that preserved the behavior of every existing document. Notion created a General teamspace and moved every existing page into it, with permissions intact.

The test for any rollout: what does an existing customer see the morning after deployment? The answer has to be that everything works, populated with their own data, as though the feature had always been there.

The vendor absorbs#

Stripe has shipped roughly a hundred backwards-incompatible API changes without forcing a single client to upgrade. Accounts are pinned to the version of their first request and compatibility layers translate backward. Their framing is that a web API should be as stable as a power company’s voltage.

When a team says it can’t do something without making an administrator configure it first, that describes the implementation path they can see from where they’re standing. The requirement stands. The answer is to find a path that absorbs it internally, or to fund the work that builds one.

Where this stops being a design preference#

Safety by Design, the framework from Australia’s eSafety Commissioner now referenced by the EU and the OECD, rests on three principles. The first is service provider responsibility: the burden of safety should never fall solely upon the user.

That’s Tesler’s Law written as child-safety policy. In software where the output is evidence and the stakes are physical, who carries the complexity stops being a question of craft and becomes a question of whether the system is legitimate.