Consider two invoicing products, both invented for this post, each two years old.
The first started as a script that emailed a PDF to three pilot customers who paid by check. Then it added a card payment link, because one customer asked. Then reminders, because the finance lead was sending them by hand. Then multiple currencies, when the first European customer signed. Each step shipped to people already using the step before it.
The second started as a forty-page specification covering every one of those features and a dozen more, built in parallel by four teams, and launched complete.
The first one is easy to imagine still running. The second is easy to imagine being rewritten. That intuition has a name.
Gall's Law is the observation that every complex system that works grew out of a simpler system that worked, and that a complex system designed all at once from scratch rarely works and can't be patched until it does.
Where the law comes from
John Gall was a pediatrician in Ann Arbor, Michigan, who spent his spare time collecting examples of systems that failed. He published them in 1975 as General Systemantics, a book whose full subtitle runs on for several lines and ends by recommending itself to "scientists, engineers, laboratory workers, administrators, public officials, systems analysts, etc., etc., etc., and the general public." Quadrangle, the New York Times book company, reissued it in 1977 as Systemantics: How Systems Work and Especially How They Fail. Later editions followed in 1986 and, as The Systems Bible, in 2002.
The subtitle sets the tone: the book is a deadpan send-up of systems theory, and many of its laws are jokes with a point. One of them stuck harder than the rest: "A complex system that works is invariably found to have evolved from a simple system that worked." Gall paired it with a second sentence, whose exact wording changed between editions: a complex system designed from scratch never works and can't be fixed into working, so you have to start over with a simple system that works.
Software people adopted it early, and it has since become a standard argument for shipping something small and growing it. It's worth reading as Gall offered it, though: a field observation, delivered with a straight face in a funny book, with no proof attached.
Why the scratch design fails
The law states what happens. One explanation for why it happens is feedback.
A simple system that works is already in contact with reality. Its users, its data and its failure modes are real, and every change after that is a small bet checked against something true. The working system keeps correcting the people who build it.
A complex system designed from scratch makes all of its bets at once, before any of them can be checked. Each assumption in the specification might be right on its own. The trouble is that the design depends on all of them being right together, and the first contact with real use tests every one of them in the same week. When several are wrong, they're wrong in combination, and the fault isn't in any one part that can be patched. That's the part of Gall's corollary engineers recognize: the system can't be repaired into working because nothing about it ever worked to begin with.
The rewrite is a scratch design
Gall's Law has a sharp edge for teams that already have a working complex system. Sooner or later someone proposes to replace it with a clean one, designed properly this time. That proposal is a complex system designed from scratch, which is the exact case the law warns about.
The rewrite is tempting because the old system looks arbitrary. Why are reminders sent from a different service than invoices? Why does currency conversion happen at send time and not at payment time? From the code alone, each of these looks like an accident a careful designer would remove. Many of them were answers to something that happened: a customer, an outage, a regulation, a constraint that was real when the step was taken.
Coding agents raise the stakes. They have made it cheap to produce a large, coherent-looking system in one pass, and asked to "clean this up," they can propose exactly the from-scratch design Gall described. Cheaper construction lowers what a rewrite costs. It doesn't change whether the result works, because the bets in the design still have to meet reality all at once.
Where Brief fits: the path, written down
If every working complex system is the end of a path, then the most useful thing to know about one is the path: which simple version came first, what changed it, and why each step was taken. The code shows where the path ended. It doesn't show the path. That's the record Brief keeps, as the team's decisions with their reasons, linked to the features they shaped.
Here's what the path of the first invoicing product looks like as a record of decisions. The format is illustrative. The content is the point.
Email invoices as PDF attachments
Why: three pilot customers, all paying by check
Add a card payment link to each invoice email
Why: largest pilot customer asked to stop writing checks
Send reminders from a separate scheduler service
Why: invoice service went down during month-end; reminders must not
Convert currency at send time, locked for 30 days
Why: EU customers disputed amounts that changed after the invoiceEvery line is a step from one working system to the next. Each was captured where it was made. When the call happened in a Slack thread, mentioning @Brief there uses the thread as context, and Brief may propose a structured decision from the conversation for you to confirm or edit. From the terminal, brief decisions create --decision "Convert currency at send time, locked for 30 days" --rationale "EU customers disputed amounts that changed after the invoice" records the same thing.
Three things change once the path is on record.
The rewrite proposal meets the reasons first. Before anyone starts the clean version, an engineer or agent can run brief ask --mode check "We plan to move reminders into the invoice service", and Brief validates the approach against the decisions already on record. The month-end outage comes back before the design does. Sometimes the reason no longer applies and the change is right. Either way, the team is deciding against the real history and not against the guess the code invites.
Each step says when it should be revisited. Gall's Law says working systems change one step at a time, and a step is only right while its reason holds. Brief lets a decision carry a plain-language expiry condition: add --expires-when "when our payments provider locks exchange rates" to the currency decision, or fill in Re-evaluate when in the app. When a step is replaced, archiving the old decision takes it off the regular list while Show archived still finds it, and a recorded decision's History shows its status changes, who made them, and any reason given. A newcomer can follow the sequence the system actually took, which is the sequence the next step has to start from.
Agents start from the path. Brief's agent setup has coding agents call brief_get_onboarding_context at the start of every session, which loads the team's decisions along with its personas, recent work and customer insights. An agent asked to extend the invoicing product sees why reminders live where they live before it proposes moving them.
The record doesn't make the law optional. A path written down doesn't make a from-scratch design work, and sometimes a system really has drifted far enough from its reasons that starting over with a simple working version is Gall's own advice. The record holds what the team captured and nothing else; steps nobody recorded still look like accidents. What it gives a team at the moment someone proposes the clean rewrite is the one thing the code can't: the order in which a working system was actually built, and the reason for each step.
Which parts of your system look like accidents today, and how many of them would turn out to be answers if you could see the step that put them there?
Objections
What is Gall's Law?
Gall's Law is the observation, from John Gall's 1975 book on how systems fail, that "a complex system that works is invariably found to have evolved from a simple system that worked." Gall added that a complex system designed from scratch never works and can't be fixed into working, so the remedy is to start over with a simple system that works and grow it.
Who was John Gall?
John Gall was an American pediatrician in Ann Arbor, Michigan, who wrote about systems as a sideline. His book first appeared in 1975 as General Systemantics, was reissued in 1977 as Systemantics: How Systems Work and Especially How They Fail, and later appeared in a 1986 second edition and, in 2002, as The Systems Bible. The book is a tongue-in-cheek critique of systems theory, and the law is an observation offered without proof.
Does Gall's Law mean you should never rewrite a system?
No. Gall's own advice for a complex system that doesn't work is to start over, but to start with a simple system that works and grow it, not with a complete new design. The law argues against replacing a working system with a large design built all at once, because that design has to meet real use with every assumption untested.
How does Brief help with Gall's Law?
Brief keeps a team's decisions and their reasons, which is the record of how a working system grew from simple to complex. Teams capture decisions from Slack with an @Brief mention or from the terminal with brief decisions create, check a proposed change or rewrite against existing decisions with brief ask --mode check, and attach a Re-evaluate when condition so each step says when it should be revisited. Coding agents load those decisions at the start of a session, so they see why a system is shaped the way it is before proposing to change it.