Tesler's Law: Why Complexity Never Actually Disappears

A Law Built to Win an Argument, Not Just Describe One

In the mid-1980s, Larry Tesler was working at Xerox PARC on what would become the language of interaction design — the standards that later shaped how desktop computers behaved. He noticed something that seemed obvious once stated but wasn't obvious to the engineers around him: every application carries a fixed amount of complexity that can't be removed, only relocated. The only real decision is who ends up carrying it — the person building the software, or the person using it.

Tesler didn't publish this as an academic paper. He coined it as a persuasion tool, aimed at Apple management and outside software vendors, to argue that companies should absorb complexity during design rather than pass it downstream to users. The law had a practical goal from day one: get engineers to do the harder work up front so nobody else had to.

Complexity Has to Live Somewhere

The core claim is specific, not vague: a system's irreducible complexity is conserved, not eliminated. Simplify an interface, a process, or an explanation past a certain point, and the complexity someone removed doesn't vanish — it shows up later, usually as confusion, a support call, or a mistake made by someone who needed context that got stripped out.

Tesler's own example was blunt. If a million users each waste a minute a day working around complexity an engineer could have absorbed in a week of extra effort, the design failed — not because it was too complex, but because it put the complexity in the wrong place. The complexity was never optional. Only its location was.

The Same Law Applies Past Software

Tesler was talking about interface design, but the underlying claim isn't specific to software. Any time someone compresses a complex idea into a simpler explanation, the same conservation applies. The complexity in the original idea doesn't disappear when the explanation gets shorter — it either gets absorbed by the person doing the explaining, who does the harder work of figuring out what can be safely cut, or it gets dumped on the listener later, as a gap they discover only once the simplified version stops matching reality.

A good simplified explanation is one where the explainer has already done that absorption work — deciding which details are load-bearing and which aren't, then carrying the load-bearing ones through even in the short version. A bad one just deletes detail indiscriminately and calls the result simpler, leaving the listener to discover later, usually at an inconvenient moment, which parts were actually necessary.

Where the Complexity Actually Goes When It's Cut Wrong

This shows up constantly in technical documentation, onboarding material, and product design, not just in casual explanation. A setup guide that skips a genuinely necessary step to look shorter doesn't make the step unnecessary — it makes the user hit the missing step later, with no guide in front of them and less context than they'd have had if it were included from the start. The complexity moved. It didn't shrink.

The same pattern shows up in one-line summaries of complicated situations — a policy, a legal case, a technical failure. Cutting a summary down to one clean sentence doesn't make the situation simpler. It just relocates whatever got cut into the reader's blind spot, where it resurfaces the first time they act on the summary as if it were complete.

Tesler's Own Answer to Where It Should Go

Tesler was explicit about which direction the complexity should move: toward whoever has more capacity to absorb it, usually the person building the thing rather than the person using it once. His reasoning was economic as much as ethical — a single engineer spending extra effort once is cheaper, in aggregate, than a million users each losing time to a shortcut that was never actually simpler, just shorter.

That same math applies to explaining something to one person versus explaining it to many. The more people will hear a given explanation, the more worth it becomes to spend real effort deciding what can be cut safely — because every piece of complexity left unaccounted for gets multiplied by everyone who has to rediscover it on their own.