I've only ever built something that worked by first building a couple of things that didn't. No amount of theory or specification can replace what you learn by actually building and interacting with a system. Accept that there will be a version 2.

  >> If you ignore a dependency and try to fix it later, it will be more expensive. More time, more effort, more thinking. And it will require the same level of coordination that you tried to avoid initially.

Would add that, if you only address fixing these dependencies one by one, as they manifest, i.e. continue in the evolutionary way, you risk resolving those parts of your Big System into some local minima; over time, you go from lots of little presumed-independent bubbles, to an intermediate stage with fewer but larger medium sized bubbles. When those get into conflict, the pain will be correspondingly greater.

>In a sense, it is the difference between the way an entrepreneur might approach doing a startup versus how we build modern skyscrapers. Evolution versus Engineering.

There are core differences in software engineering that, unlike in construction work:

- making changes is often cheaper

- we might not know beforehand everything that is needed to be built, especially unknown unknowns

I would still agree that the truth is somewhere in between, but I would argue that, for software, it's closer to the evolutionary approach.

"It’s not that you could cut the combined complexity in half, but more likely that you could bring it down to at least one-tenth of what it is today, if not even better. It would function better, be more reliable, and would be far more resilient to change. It would likely cost far less and require fewer employees as well. All sorts of ugly problems that they have now would just not exist."

Incidentally this highlights a problem when using chatbots to build large software projects that are intended to be used for a long period of time.

The key is not how much code you can add but how little you can get away with.

Chatbots only solution ever is to ADD code. They're not good at NOT writing code or even deleting it because after all the training set for the lines of code that do not exist is an empty set. Therefore it's impossible to train a robot to not write code.

What's better than generating 10kloc really fast? Not having it in the first place.

Wow that's a good piece. It propelled me into writing this: https://dev.to/itay-maman/the-elephant-in-the-room-systems-t...

In short: the tension described in "systems thinking" is the same one as the one between "spec driven" vs. "iterative prompting"

    > you lay out a huge specification that would fully work through all of the complexity in advance, then build it.

I have tried this a couple of time even for small projects ( a few sprints ), and they never worked out. I'd argue it never works out if you are doing non-system programming projects, and only has a theoretical non-zero possibility to work out for system programming projects, and perhaps a 5-10% to work out for very critical and no patch possible projects (like moon landing).

Because requirements always change. Humans always change. That's it. No need to elaborate.

lol this article is like the waterfall manifesto.

Nah I’m good. I’ve watched system architecture framework views be developed. Years of prep and planning. System is released and half the employees that had requirements no longer work there and the business already pivoted to a new industry focus.

There’s a reason we went this way in software development a quarter century ago.

Software is not a skyscraper.

Build what you know you need now. Refactor when things grow. Doesn't have to be rocket science.

Show me an example of a large complex software system built from spec rather than evolved.

> Also, the other side of it is that evolutionary projects are just more fun. I’ve preferred them. You’re not loaded down with all those messy dependencies. Way fewer meetings, so you can just get into the work and see how it goes. Endlessly arguing about fiddly details in a giant spec is draining, made worse if the experience around you is weak.

IMO the problem isn't discussing the spec per se. It's that the spec doesn't talk back the way actual working code does. On a "big upfront design" project, there is a high chance you're spending a lot of time on moot issues and irrelevant features.

Making a good spec is much harder than making working software, because the spec may not be right AND the spec may not describe the right thing.