Gall's Law¶
Core Idea¶
A complex working system is reached only by incremental modification of simpler working systems, never by from-scratch design of the whole. The sharper-than-"iterate" claim is that the intermediates themselves must work: a path through an intentionally non-working intermediate fails there, because the team cannot debug, fund, or diagnose against a broken base.
How would you explain it like I'm…
Start With a Small Tower
If you want to build a really tall tower of blocks, you can't just plop the whole giant tower down at once; it would fall over. You start with a small tower that stands up by itself, then add a little, and check it still stands, then add a little more. A big thing that works almost always grows from a smaller thing that worked. You can't skip straight to the giant version.
Every Step Must Stand
Gall's Law says that complex things that actually work are almost always built up step by step from simpler things that already worked, not designed all at once from scratch. If you try to design a big complicated system in one giant leap, it will almost never work, and patching the broken version usually won't save it. The trick is that each in-between version has to work on its own, not just the final one. A half-built bridge that can't carry anything doesn't help you get to the finished bridge. So the real path goes through a chain of working versions, each good enough to stand on its own while you improve it.
Working Steps All the Way
Gall's Law is the observation that complex working systems are reached by incremental modification of simpler working systems, not by from-scratch design of the full target. Stated negatively: a complex system designed all at once, without passing through working intermediate versions, will almost never work, and once broken, patching it usually won't reach the working state, because the working states reachable from the broken design aren't connected to the target. What makes this sharper than 'just iterate' or 'start small' is the requirement that the intermediates themselves must work. A path that runs through an intentionally non-working stage, like a half-built bridge or a half-deployed protocol, typically fails at that stage even if the final target would have worked, because you can't debug the next increment against a broken base and the broken version can't attract the resources or users to fund the next step. The dual claim is that complex systems we see working today are almost always evolved descendants of simpler working ancestors, with the chain of viable intermediates still visible in vestigial features and legacy interfaces.
Gall's Law is the structural observation that complex working systems are reached by incremental modification of simpler working systems, not by from-scratch design of the full target system. Stated negatively: a complex system designed from scratch, without passing through a sequence of working intermediate versions, will almost never work; and if it does not work, no amount of patching the failed design will reach the working state, because the working states reachable from the broken design are not connected to the target. The path to a working complex system runs through a connected chain of working intermediates, each viable on its own terms. The pattern is sharper than 'iterate' or 'start small': it specifies that the intermediates themselves must work. A development path that passes through an intentionally non-working intermediate (a half-built bridge, a half-deployed protocol, a partially-rebuilt constitution) typically fails at the intermediate even if the final target would have worked, because the team cannot debug the next increment against a broken base, because the broken intermediate cannot recruit the resources or users needed to fund the next step, and because the failure modes of the broken intermediate are not diagnostic of the target's failure modes. The dual claim is that complex systems observed to work today are almost always evolved descendants of simpler ancestors that worked, with the chain of viable intermediates traceable in their structure: vestigial features, legacy interfaces, archaic conventions, the etymology of standards. The structural content is a claim about which paths through design-space are constructible at all: viability is a predicate on each waypoint, and only chains whose every waypoint satisfies it can be traversed.
Broad Use¶
- Software engineering: large from-scratch rewrites repeatedly fail; "you can't ship a rewrite" while working successors grow incrementally.
- Biological evolution: a complex organ implies a chain of functional intermediate organs, formalized as connectivity of the viable region of genotype-space.
- Constitutional design: working constitutions grow from earlier working ones; from-scratch impositions in fractured states frequently collapse.
- Urban planning: cities that work grew by layering working sub-systems; high-modernist from-scratch designs "fail to come alive."
- Venture methodology: the minimum-viable-product doctrine is Gall's Law made operational — every release must be a working product.
- Standards and protocols: successful protocols accreted from working ancestors; from-scratch replacements struggle against incumbents.
- Habit formation: incremental programs that establish each small change beat wholesale life-overhaul programs.
Clarity¶
Separates "this design is wrong" from "this development path is wrong," and reframes vestigial features — legacy APIs, archaic procedures — as the signature of viable-intermediates evolution rather than design errors.
Manages Complexity¶
Reduces an open-ended planning problem ("how do we reach that complex target?") to a structured search for a path whose every waypoint is independently viable — a sequence of local viability questions.
Abstract Reasoning¶
Treats design-space as a graph with a viability predicate on each vertex: the target is reachable only if a path of all-working waypoints connects to it, so a from-scratch jump lands in a disconnected, unreachable component.
Knowledge Transfer¶
- Biology → computation: the viable-intermediates requirement passed into evolvability theory and the "deceptive landscape" problem in evolutionary algorithms.
- Software → product management: "never rewrite from scratch" transferred across industries.
- Lean startup → public sector: the MVP doctrine moved into corporate innovation and agile-transformation programs.
Example¶
A government modernizing its tax system by a single big-bang cutover is predicted to fail — no working intermediate to debug or fall back on; modernizing the smallest isolable piece first, shipping it, then evolving one viable increment at a time succeeds because each waypoint works.
Relationships to Other Primes¶
Foundational — no parent edges in the catalog.
Children (1) — more specific cases that build on this
- Minimum Viable Product (MVP) is a kind of Gall's Law — The file: MVP is 'Gall's Law operationalized for the venture substrate' — the prime is strictly more general (its viability predicate is 'works in its own environment', not 'customers pay'). galls_law is the parent; mvp keeps its satisficing/iteration parents.
Not to Be Confused With¶
- Gall's Law is not the Minimum Viable Product doctrine because MVP judges viability against market fitness, whereas Gall's Law's predicate is "works on its own terms" — which for a proto-eye means a survival edge, not a customer.
- Gall's Law is not Iteration because iteration is bare repetition that says nothing about the intermediate state, whereas Gall's Law constrains every waypoint to independently work.
- Gall's Law is not Path Dependence because path dependence is the descriptive claim that history constrains options, whereas Gall's Law is the constructive claim that only all-viable paths can be built at all.