Gall's Law and shipping v1

A working production system is almost always an evolved descendant of something simpler that already worked. Pretending otherwise is how you fund a rewrite instead of a product.

A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.

John Gall published that in General Systemantics (1975), a handbook on how systems fail. The wording above is quoted on his Wikiquote page from page 71 and often goes by Gall’s law when engineers talk about architecture.

What Gall is pointing at is not mysticism about complexity scores. It is a pattern in the wild. Integrations, failure modes, and human habits only show up under load. A simple system that runs for real users (or holds real traffic) forces those facts into view while the surface area is still small enough to fix.

Treat the first shippable slice like the seed, not the costume. Wire one critical path end to end on the same rails you plan to run in production. Keep the ritual docs and six-month roadmaps secondary to whether tonight’s deploy still works when something you did not model comes calling.

When teams skip that step and bolt twelve subsystems together before anything is exercised in anger, Gall’s corollary is what you buy. YAGNI is the feature-level habit that keeps the first working core small enough to evolve. You do not patch your way to trust. You restart from a smaller working core or you pay interest until you do.