Law of Conservation of Complexity¶
Core Idea¶
Every problem carries an irreducible complexity floor that must be handled somewhere by someone; design can shift where it lives — which party, which moment, which representation — but cannot reduce the total below the floor, so a simpler interface implies a more complex implementation or a more complex user.
How would you explain it like I'm…
The Squishy Lump
Imagine a lump of clay that you can squish into different shapes but can never make smaller. If you push it flat on one side, it bulges out somewhere else. A hard job is like that lump: making it look easy in one spot just moves the hard part to another spot — it never disappears.
Work Never Vanishes
Every problem has a certain amount of hard stuff in it — the work, the tricky decisions, the weird special cases — that someone has to deal with somewhere. The Law of Conservation of Complexity says you can move that hard stuff around, but you can't make the necessary part of it go away. If you make a gadget super simple to use, the hard work just shifts onto the people who built it. If you make it cheap and simple to build, then using it gets harder. It's like squeezing a balloon: press it in one place and it pops out in another.
The Complexity Floor
The Law of Conservation of Complexity says every problem carries an irreducible amount of complexity, all the work, distinctions, and edge-cases, that has to be handled by someone somewhere. Design can shift where that complexity lives, who bears it, when, and in what form, but it can't push the total below that floor. So a simpler interface implies a more complex implementation; a simpler implementation implies a more complex user. This is sharper than a plain tradeoff: a tradeoff just says gaining on one side costs you on another, while this law adds a hard floor that no clever arrangement can erase, only relocate. There's a separate, real move called floor reduction, actually shrinking the minimum by dropping requirements or re-scoping, and the discipline is to tell that apart from merely shoving the burden onto someone else. One caveat: the law only binds the necessary floor, so useless bloat sitting above the floor genuinely can be deleted, not just moved.
The Law of Conservation of Complexity holds that every problem carries an irreducible amount of complexity, work, distinctions, decisions, edge-cases, that must be handled somewhere by someone. Design choices can shift where the complexity lives (which party bears it, at which moment, in which representation), but cannot reduce the total below that floor; hiding it in one place forces it to bulge in another. The commitment has two parts: a floor, an irreducible minimum set by the problem itself, and a shift relation, a degree of freedom moving complexity between parties, layers, or moments without affecting the floor. This is what distinguishes the prime from a generic tradeoff, which asserts gain-versus-loss but no irreducible minimum. A separate operation, floor reduction, genuinely lowers the minimum by re-scoping, dropping requirements, or exploiting previously-invisible structure, and the discipline the prime imposes is to keep relocation and reduction apart and to name the party who absorbs whatever is relocated. The cleanest place to see the shift is across an interface: when a task is split between system and user, designer and consumer, regulator and regulated, the conservation runs over the sum of burden on both sides, so simplifying one side merely loads the other. This yields the law's characteristic user-versus-developer tension: hiding an option behind a default relieves the user but loads the system with more code paths and support burden. One caveat sharpens the claim: the conservation binds only the necessary floor, while accidental complexity sitting above it, bloat surviving only by implementation choice, genuinely can be removed rather than relocated. Articulated by Larry Tesler for human-computer interaction, parallel forms appear in security, regulation, education, and contracting.
Broad Use¶
- Human-computer interaction: Tesler's original — a free-text field shifts parsing complexity from the user to the application; a strict format shifts it back.
- Software architecture: implicit versus explicit configuration, declarative versus imperative APIs, type inference versus annotation each allocate complexity across layers.
- Regulation: form simplicity trades against agency-adjudication burden; pre-clearance against ex-post enforcement.
- Security engineering: strong-default security raises key-management complexity; permissive defaults shift it to incident response.
- Education: simpler textbooks pay for accessibility in heavier teacher preparation or narrower coverage.
- Healthcare: a patient-friendly decision aid moves complexity onto the clinician; a clinician-friendly protocol moves it onto the patient.
Clarity¶
Makes visible that "simpler X" almost always means "more complex Y," forcing designers to name the party who absorbs the relocated burden rather than claim it was eliminated.
Manages Complexity¶
Replaces an unbounded search for cleverness ("make the hard part disappear") with a bounded allocation problem over a known floor: enumerate the parties who could absorb it, score each by cost-of-absorption, and assign the residue.
Abstract Reasoning¶
Distinguishes a shift (relocates the floor's burden, total unchanged) from a genuine floor reduction (re-scoping, dropping requirements, exploiting newly-visible structure) — and binds only the necessary floor, leaving accidental bloat freely removable.
Knowledge Transfer¶
- Regulatory design from HCI: the floor-plus-shift calculation justifies pre-clearance for high-frequency low-stakes decisions and ex-post enforcement otherwise.
- API design: it underwrites "make the easy case easy and the hard case possible."
- Contracts and clinical protocols: the same "who bears it most cheaply?" audit ports unchanged.
Example¶
A flight-booking site choosing a single free-text search box versus a structured multi-field form does not eliminate the complexity of disambiguating a trip — the box pushes parsing onto the system, the form pushes field-by-field decisions onto the user — and the right choice depends only on which party can bear it more cheaply.
Relationships to Other Primes¶
Parents (2) — more general patterns this builds on
- Law of Conservation of Complexity presupposes Complexity — The law presupposes complexity (the quantity it conserves) and adds two specific claims — an irreducible FLOOR and a SHIFT relation that relocates burden without lowering the total. The file: complexity is the embedding-nearest (0.95) and the quantity the prime is about but not identical to.
- Law of Conservation of Complexity presupposes, typical Trade-offs — Tesler's law is adjacent to trade_offs but is CONSERVATION not exchange (file 'Not': it conserves the SAME quantity across an interface rather than swapping one good for another). Recorded as a weak presupposes-edge into the trade/constraint family; NOT a child of conservation_laws (those are exact/physical, this is a defeasible design heuristic over the necessary floor). [merged from teslers_law]
Path to root: Law of Conservation of Complexity → Complexity
Not to Be Confused With¶
- Law of Conservation of Complexity is not Complexity itself because the prime adds an irreducible floor and a shift relation, whereas complexity is the bare property of having many interacting parts.
- Law of Conservation of Complexity is not a generic Trade-off because it asserts an irreducible minimum no allocation can eliminate, whereas a trade-off asserts only an exchange rate with no floor.
- Law of Conservation of Complexity is not a physical Conservation Law because its floor can be lowered by re-scoping, whereas a physical conservation law rests on a symmetry guaranteeing exact conservation.