#12 – Obey Gall’s Law: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.

Gall’s Caveat: Working big systems come from working smaller systems – but not every small system can solve/scale to big systems.

Healthcare.gov (the health insurance exchange website linked to the Affordable Care Act) was a disaster by almost all metrics. A report by the Office of Inspector General offers ten key reasons for the disaster, everything from lack of clear leadership, an overly bureaucratic culture, failures of integration, communication, execution, and oversight. The report is thorough, but too vague. Instead, we should have paid attention to Gall’s Law.

In 1975 a pediatrician and systems design theorist John Gall wrote the book Systemantics: How Systems Really Work and How They Fail, in it, he wrote “A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.” There’s a tremendous amount of wisdom wrapped up in those lines. Wisdom that explains why lots of great big ambitious projects become huge failures. Healthcare.gov is one, various megaprojects in Dubai, Boston’s Big Dig, Portland’s I-5 bridge, and countless other projects that devolved into massive cost overruns and failure to deliver on major promises.

Instead, extreme programming and the requirement that startups have working prototypes have espoused this simple but functional operating method based on Gall’s observation. In my own work at Intel Labs and other new products, getting a working proof of concept 100% nailed before you move to production assures success is possible while failures happen while things are still cheap.

Which brings us to Jennifer Pahlka’s article where she covers a number of other observations. One of which is Mike Byrne. Byrne built the broadband map for the Federal Communications Commission (FCC) and estimated that most government tech projects could cost 10% of what they do and still provide 85% of the functionality. Apple works this way as well to a certain degree. They do not provide an experience for everyone. They focus the problem, solve it in a particular way, and ignore the critics. They don’t always try to cover all cases nor provide all the features people want – but the cases they do cover are expected, and usually are, rock solid. And that has led them to be the biggest success in tech.

So, instead of designing a system to handle every possible case like was done with Healthcare.gov, it’s ok to leave some cases on the table for manually addressing via phone centers. But the core should work flawlessly.

Gall’s Caveat of Small Systems

There is one caveat Gall observed. This is something I have encountered with younger and recent developers/designers. Some teams/designers rush to a working prototype which is flashy and makes a big splash with some aspects of the key functionality, but quietly and knowingly doesn’t address a number of critical requirements that the design absolutely cannot deal with. They usually hand wave that those will be solved by someone else/some other time – when the reality is that a complete re-write or re-design would be required to handle the requirement. In my experience, that usually happens after they plan on being long gone with the money and awards for the first part. This is probably why we’re see a large number of the Forbes 30 under 30 crowd ending up in jail for fraud.

Gall wrote this caveat: Working big systems come from working smaller systems – but not every small system can scale nor handle all cases it needs to handle. If you need to handle a number of key design requirements, you need to have a working (small) system to solve each of them. Then you combine them.

You must do the design and smaller proven system work for all the things you do need to handle even if you do not deliver those parts today. Do not use simplicity and just building a small core to handle 85% of the cases to avoid the work of ensuring you can handle the remaining 15% of cases. You should always have a design and a plan, even if you don’t need it today (or ever). Maybe that plan is that call centers will handle the remaining 15% – maybe forever. But when things are planned, they can be accounted for, have fixes planned, and not be a huge surprise.