> 23. 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.
Let me present the Paige Compositor. A typesetting machine if you like, made from 18,000 precision made parts in 1877. Well, 1877 is the start year of the contract. The project went on for about 15 years. 6 machines were ever made (out of 4,000 ordered). They kept failing.
Meanwhile, a much more limited (initially) machine arrived on the scene, the Linotype machine. It was successfull and did run the world's news and magazine press for the next 100 years.
I see the obvious examples of complex systems failing, but we also have so many other complex systems that sure have their shares of issues, but I am not sure we can mark as failed.
For instance government constitutions are arguably complex, and formed from scratch.
Or to stay in the tech sphere and look at the problem from the other end, is it possible to build anything that hasn't effectively evolved from something more simple ? If tomorrow I'd want to build a whole new rocket from scratch, I'll need to build the parts piece by piece, and test them before assembly.
Do we consider these tests to be simpler systems that are proved to work, thus if my rocket design happens to work, it evolved from simpler systems that got combined ? Does my design come from so many other designs I've seen and learn, and so is an evolution of these past designs ? etc.
My core question would be, does that law have any practical impact in our field ?
The most salient example to me is microservices. It's unfortunately quite common for a microservices architecture to be invented during a whiteboarding session.
Incremental approaches are limited. A basic example of this is scaling. A chemical process worked out in a lab cannot be incrementally scaled for effective production with bigger test tubes. The entire production process must be designed again from scratch.
Incremental approaches to designing a control system with many if statements will never evolve into a PID controller. Nor will a PID controller be evolved into being able to handle non-linearities.
Scrum may be effective as an organisational process at a team level, but will fail utterly if it is applied to the entire organisation.
Incremental approaches optimise, but that’s all they can do.
This is a known problem in math, it's called a local maximum.
It's a function of where you start on the graph. Experience and understanding can let you start in a different place on the graph that may be less efficient but have a higher local maximum.
but you don't usually just jump from one peak to another. there's series of repeat failures that have to happen to get to the next mountain to traverse(usually there could be point solutions I suppose)
With optimization functions, the general process is pick a point, iterate until a local maximum, pick a new point, iterate until a local maximum, and repeat until you have an answer you're comfortable with. You might run out of time, or evaluate enough of the space that you're confident you've found an anawer.
When you apply the same idea to iterating on a product, or an engineering problem, the end result of your iteration depends on you choosing a good starting point. that's where experience comes in - you don't start all the way at the beginning, you start at the place where you know you can iterate to higher maximum. You've already had those repeat failures in the past.
A slightly silly but less abstract example. Let's say im brought in to a company to help solve the problem that the developers can't work on the project together because they can't share code.
_A_ starting point is a network drive, and you can iterate on that with file locks and faster networks, but you hit a local maximum. You then decide to use a database or something, and eventually you reinvent CVS.
Meanwhile, an experienced developer will skip all of that and start with git, and iterate on things like code review, merge pipelines.
This is awesome because I’d landed on the same concept but via evolution, especially a section in the Blind watchmaker where Dawkins implores on one fundamental requirement for evolution, which is that every step in the evolutionary process the individuals need to have a functional version of the trait. You can’t just shut down the process to retrofit things. Evolving eyes from light sensitive cells means that the organoid in every intermediate step should be a functional light detector that’s slightly better than the previous iteration if not the same.
This is a great, but absolutely not necessarily the only, way of writing software. As mentioned by other replies this is maybe not even possible in some fields. And as Dawkins points out, it’s is absolutely not the most efficient way and you don’t explore the full efficiency landscape by a long shot. But it works, and is predictable. I’ve had great success in software by following this rule.
It is also highly resilient to unpredictable organizational politics and inefficiencies because from the moment of having an MVP, you always have a functioning product.
> Evolving eyes from light sensitive cells means that the organoid in every intermediate step should be a functional light detector that’s slightly better than the previous iteration if not the same.
This is not entirely true, because there is horizontal gene transfer, and serendipitous combinations, even of "junk" DNA. For example, eyes started off as ordinary brain cells that just happened to have a light-sensitive chemical in them: melatonin. The melatonin could have had another non-photosensing use prior to this, or it could even have been a mere byproduct of some other process.
I think a much more profound one is that in complex systems, there are usually workings that are not obvious to the observers. And so, by manipulating these systems, they will fail in unexpected ways. I'm not sure why OP can't think of a complex system designed from scratch - how did, for example, the Large Hadron Collider get designed? Starting from a nice and simple particle collider, and evolving from there?
> 23. 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.