22 Mar 2019
I came across an interesting theory while reading Hacker News yesterday called Gall's Law. John Gall was an author an pediatrician, but he has been described as a "systems theorist". His law plainly states:
“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 simple system.”John Gall
This strikes me as being intuitively true and quite profound. The vast majority of successful complex systems have their origins in simple seed projects. Systems like cellular networks and internet infrastructure have been the culmination of decades of work, all of which started by connecting two points together with a single wire. Large mature software systems such as operating systems have likewise been a group effort by many people over many years, often starting with a simple base system (or "kernel").
This principle appears to have repercussions in many industries, and feels almost like a natural outcome of the Pareto principle. A small working system has disproportionate impact on the problem you want to solve. If we take the percentages described in the Pareto principle verbatim, we should expect a complex system to take ~5 times the resources to produce than a simpler system which solves many of the same problems.
This idea is also one of the founding tenets of the Agile project methodology. It is easier to iterate over a working (but incomplete) solution than to solve all problems at once in a timely manner. For example, think about approaching the problem of designing and implementing a stock-exchange. It is easier to start with the base problem:
How do I design a fault-tolerant concurrent bidding system?
This simpler statement of the problem removes the distraction of what is specifically stock-exchangey, and illustrates the core problem of a stock-exchange: making a real-time auction system. It may even be better to break this into an even more fundamental problem:
How do I match two peers to perform a transaction?
Without solving this problem, all other thinking and design is null and void.
It is fascinating that such a deep insight was not identified by an engineer or a software developer, but a doctor. This is not to say that I don't believe people from other industries can identify these kinds of patterns. On the contrary, I think that the software industry has a lot to gain from other disciplines. The idea that only engineers can make statements about complex systems is a false one. Compelling ideas such as these can come from anyone.