[bestham]

“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.” Gall’s Law

[jandrewrogers]

Some systems require a total commitment to the complexity because it is intrinsic. There is no "simple" form that also works, even if poorly. In many contexts, "systems thinking" is explicitly about the design of systems that are not reducible to simpler subsystems, which does come up in many types of engineering. Sometimes you have to eat the whole elephant.

There is a related phenomenon in some types of software where the cost of building an operational prototype asymptotically converges on the cost of just writing the production code. (This is always a fun one to explain to management that think building a prototype massively reduces delivery risk.)

[pardon_me]

This is the point we are at now with wide-scale societal technologies; combining the need for network effects with the product being the prototype, and no option but to work on the system live.

Some projects have been forced so far, by diverting resources (either public-funded or not-yet-profitable VC money), but these efforts have not proven to be self-sustaining. Humans will be perpetually stuck where we are as a species if we cannot integrate the currently opposing ideas of up-front planning vs. move fast and break things.

Society is slowly realizing the step-change in difficulty between projects in controlled conditions that can have simplified models to these irreducibly complex systems. Western doctors are facing an interesting parallel, now becoming more aware to treat human beings in the same way--that we emerge as a result of parts which can be simplified and understood, but could never describe the overall system behavior. We are good examples of the intrinsic fault-tolerance required for such systems to remain stable.

[nasretdinov]

I think the important part here is "from scratch". Typically when you're designing a new (second, third, whatever) system to replace the old one you actually take the good and the bad parts of the previous design into account, so it's no longer from scratch. That's what allows it to succeed (at least in my experience it usually did).

[bluGill]

These days software has been done a lot. You should be able to find others who have done similar things and learn lessons from them. Considering microservices - there are lots of people who have done them and can tell you what worked well and what didn't. Considering using QT - lots of others have and can give you ideas. Considering writing your own framework - there are lots of others: look at what they do good and bad.

If you are doing a CRUD web app for a local small business - there are thousands of examples. If you are writing control software for a space station - you may not have access to code from NASA/Russia/China but you can at least look at generic software that does the things you need and learn some lessons.

[jackblemming]

People misinterpret this and think they can incrementally build a skyscraper out of a shed.

[saulpw]

That's what happened though? First humans built sheds, then we built 2-story buildings, then taller and taller, until we built skyscrapers. Obviously it wasn't a single structure, but we did have to evolve our thinking on how to build things, we didn't just start building a skyscraper before we built a shed.

[sph]

That's exactly why software is so bad. No one ever knows their shed would ultimately have to become a skyscraper, and management doesn't allocate any budget to lay stronger foundations when expectations change; you make do with what you have.

See also: "there is nothing more permanent than a temporary solution"

[narag]

You can't physically but the logic is the same: you need beams, foundations, walls and roofs, with strenghts adjusted for scale. Software mindset :-)

In this sense, web applications haven't changed so much in the last twenty years: client, server, database...

[cpursley]

It’s actually the opposite - you actually can. The feel I'm getting reading anti-AI sentiment is people are expect one shot results out of limited context.

[codeflo]

This is often quoted, but I wonder whether it's actually strictly true, at least if you keep to a reasonable definition of "works". It's certainly not true in mechanical engineering.

[bestham]

The definition of a complex system is the qualifier for the quote. Many systems that are designed, implemented and found working are not complex systems. They may be complicated systems. To paraphrase Dr. Richard I. Cook’s ”How Complex Systems Fail” where he claims that complex systems are inherently hazardous, operate near the edge of failure and cannot be understood by analyzing individual components. These systems are not just complicated (like a machine with fixed parts) but dynamic, constantly evolving, and prone to multiple, coincidental failures.

A system of services that interact, where many of them are depending on each other in informal ways may be a complex system. Especially if humans are also involved.

Such a system is not something you design. You just happen to find yourself in it. Like the road to hell, the road to a complex system is paved with good intentions.

[narag]

IMHO, the key is where you add complexity. In software you have different abstraction layers. If you make a layer too fat, it becomes unwieldly. A simple system evolves well if you're adding the complexity in the right layer, avoiding making a layer responsible for task outside its scope. It still "works" if you don't, but it's increasingly difficult to maintain it.

The law is maybe a little too simplistic in its formulation, but it's fundamentally true.

[direwolf20]

You built this gear using the knowledge from your last gear. You didn't start with no knowledge, read a manual on operating a lathe, grab a hunk of metal and make a perfect gear the first time.

[laserlight]

> It's certainly not true in mechanical engineering.

Care to exemplify?

[McGlockenshire]

Ah, the Second System Effect, and the lesson learned from it.

[jeffreygoesto]

But this is about the first systems? I tend to tell people, the fourth try usually sticks.

The first is too ambitious and ends in an unmaintainable pile around a good core idea.

The second tries to "get everything right" and suffers second system syndrome.

The third gets it right but now for a bunch of central business needs. You learned after all. It is good exactly because it does not try to get _everything_ right like the second did.

The fourth patches up some more features to scoop up B and C prios and calls it a day.

Sometimes, often in BigCorp: Creators move on and it will slowly deteriorate from being maintenaned...

[YZF]

So true.

[smitty1e]

Came here to add this very comment. https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law