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

But I do still think there's a lot of value into coming up with a good plan before jumping in. A lot of software people like to jump in and I see them portray the planning people as trying to figure everything out first. (I wonder if we reinforce the jumping in head first mentality because people figure out you can't plan everything) A good plan helps you prevent changing specs and prepares you for hiccups. It helps by having others but basically all you do is try to think of all the things that could go wrong. Write them down. Triage. If needed, elevate questions to the decision makers. Try a few small scale tests. Then build out. But building out you're always going to find things you didn't see. You can't plan forever because you'll never solve the unknown unknowns until you build, but also good prep makes for smoother processes. It's the reason engineers do the math before they build a bridge. Not because the math is a perfect representation and things won't change (despite common belief, it's not static) but because the plan is cheaper than the build and having a plan allows you to better track changes and helps you determine how off the rails you've gone.

It is also perplexing to me that people think they can just plan everything out and give it to a LLMs. Do you really believe your manager knows everything that needs to be done when they assign jobs to you? Of course not, they couldn't. Half the job is figuring out what the actual requirements are.

That's very simple. The balanced path depends directly on how much of the requirements and assumptions are going to change during the life time of the thing you are building.

Engineering is helpful only to the extent you can forsee the future changes. Anything beyond that requires evolution.

You are able to comment on the complexity of that large company only because you are standing in the future into 50 years from when those things started take shape. If you were designing it 50 years back, you would end up with same complexity.

The nature's answer to it is, consolidate and compact. Everything that falls onto earth gets compacted into a solid rock over time, by a huge pressure of weight. All complexity and features are flattened out. Companies undergo similar dynamics driven by pressures over time, not by big-bang engineering design upfront.

> The most prevalent one, these days, is that you gradually evolve the complexity over time. You start small and keep adding to it.

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

I think AI will drive an interesting shift in how people build software. We'll see a move toward creating and iterating on specifications rather than implementations themselves.

In a sense, a specification is the most compact definition of your software possible. The knowledge density per "line" is much higher than in any programming language. This makes specifications easier to read, reason about, and iterate on—whether with AI or with peers.

I can imagine open source projects that will revolve entirely around specifications, not implementations. These specs could be discussed, with people contributing thoughts instead of pull requests. The more articulated the idea, the higher its chance of being "merged" into the working specification. For maintainers, reviewing "idea merge requests" and discussing them with AI assistants before updating the spec would be easier than reviewing code.

Specifications could be versioned just like software implementations, with running versions and stable releases. They could include addendums listing platform-specific caveats or library recommendations. With a good spec, developers could build their own tools in any language. One would be able to get a new version of the spec, diff it with the current one and ask AI to implement the difference or discuss what is needed for you personally and what is not. Similarly, It would be easier to "patch" the specification with your own requirements than to modify ready-made software.

Interesting times.

The core point they're trying to make is that agile (or similar) practices are the incorrect way to approach consolidation of smaller systems into bigger ones when the overall system already works and is very large.

I agree with their assertion that being forced to address difficult problems earlier on in the process results in ultimately better outcomes, but I think it ignores the reality that properly planning a re-write of monumentally sized and already in use system is practically impossible.

It takes a long time (years?) to understand and plan all the essential details, but in the interim the systems you're wanting to rewrite are evolving and some parts of the plan you thought you had completed are no longer correct. In essence, the goal posts keep shifting.

In this light, strangler fig pattern is probably the pragmatic approach for many of these re-writes. It's impossible to understand everything up front, so understand what you reasonably can for now, act on that, deliver something that works and adds value, then rinse and repeat. The problem is that for sufficiently large system, this will take decades and few software architects stick around at a single company long enough to see it through.

A final remark I want to make is that, after only a few years of being a full-time software developer, "writing code" is one of the easiest parts of the job. The hard part is knowing what code needs to be written, this requires skills in effective communication with various people, including other software developers and (probably more importantly) non-technical people who understand how the business processes actually need to work. If you want to be a great software developer, learn how to be good at this.

2. I would be more receptive to this argument if they had listed some famous examples of successful, large systems that were built like this. On the other hand, I can easily list many failures: FAA Advanced Automation System (1980s), IRS Tax Systems Modernization (1990s), UK NHS National Programme for IT (2000s).

3. Waterfall vs. agile is a continuum. Nobody plans everything, down to each if-statement, and nobody wings it without some kind of planned architecture (even if just inside one person's head). Where you are on the continuum depends on the nature of the problem (are all requirements known?), the nature of the team (have they done this before?), and the criteria for success (are there lives depending on this?).

4. The analogy to building a building is flawed. At large enough scale, software is like a city, and all successful cities have gradually evolved in complexity. Come back to me when someone builds a 1-million person arcology on some island in the Pacific.

5. Just as some PhDs are sensitive about being called "Doctor", some software engineers are sensitive about being "real engineers". Stop thinking about that. What we do as software engineers is immensely valuable and literally changing the world (usually, but not always, for the better). Let's stop worrying about whether or not what we do is "engineering" and focus on what we do best: building complex systems that have never before existed on earth.

> the size of the iterations matters, a whole lot. If they are tiny, it is because you are blindly stumbling forward. If you are not blindly stumbling forward, they should be longer, as it is more effective.

You are not blindly stumbling forward, you're moving from (working software + tiny change) to (working software including change). And repeat. If there's a problem, you learn about it immediately. To me that's the opposite of moving blindly.

> you really should stop and take stock after each iteration.

Who is not taking stock after every iteration? This is one of the fundamental principles of agile/lean/devops/XP/scrum. This one sentence drastically lowers my impression of the author's ability to comment on the subject.

> The faster people code, the more cleanup that is required. The longer you avoid cleaning it up, the worse it gets, on basically an exponential scale.

Unsafe tempo is as likely to happen in big-spec design projects as in small iterations. In fact, working in careful small iterations helps us manage a realistic tempo because we know we can't move faster than we can get things into production and evaluate.

The terrible outcomes listed in the same paragraph are linked to unwise practice and have nothing to do with small iteration size.

The 1980s and 90s were full of DOD-497 multi-kilogram documents being analyzed atomically to determine the specification, and they rarely came in close any of the 3 main dimensions of success: time, quality, or cost.

On the other hand, neither has Agile with a capital A, with the ceremony of documents replaced with the ceremony of JIRA tickets and t-shirts.

In a more typical modern sense systems thinking is more about relationships and wholes, rather than isolating parts, which is the traditional engineering approach.

While much of the base material on systems thinking will be based around cybernetics, it is really a complement to traditional engineering, used in parallel to identity more natural complexity boundaries and to help avoid confusion and accidental complexity.

Gregor Hohpe’s Architect Elevator is probably a good place to start on why this change in perspective is important and why investing in flexibility is crucial when there is uncertainty.

While you may have to accept this article’s definition in some groups, accepting the more modern definition will help you get jobs in places that are nicer to work.

This type of false dichotomy that is presented in the article is a warning that there is soft work to be done.

People mentioning mechanical engineering in this thread are possibly the people who may benefit most from examining the material. I encourage you to see if this is a path forward for your needs.

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.

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

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.

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.

  >> 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.

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.

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

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

Ai assistance would seem to favor the engineering approach as the friction of teams and personalities is reduced in favor of quick feasibility testing and complete planning.

- you create large number of working small apps .

- you create a spec from these apps .

- create a huge app .

- make a Dsl to make extensible .

- extend the Dsl to fit what you need in the future .

- optimize the Dsl remove obvious N+1 stuff.

The hard part is throwing away the code in each step . Both managment and devs cant stomach the reality that the code is useless at each stage prior to dsl. They cant molt and discard the shell and hence the project dies.

When they turn out to be based on false assumptions of simplicity the fallout is that the whole thing can't go forward because of one of the details.

Evolutionary systems at least always work to some degree even if you can look after the fact and decide that there's a lot of redundancy. Ideally you would then refactor the most troublesome pieces.

That feels like a straw man to me. This is not a binary question. For each small design decision you have a choice about how much uncertainty you accept.

There are no "two schools". There is at least a spectrum between two extremes and no real project was ever at either of the very ends of it. Actually, I don't think spectrum is a proper word even because this is not just a single dimension. For example, speed and risk often correlate but they are also somewhat independent and sometimes they anti-correlate.

In fact, this is how you build an aerospace program, satelite, and more.

It is even possible to develop software with agile processes in such a framework, even though strictly speaking it’s not fully agile.

It didn't work, even for the "large" systems of that time: and Booch had worked on more than a few. The kind of "system" the OP is describing is vastly larger, and vastly more complex. Even if you could successfully apply the waterfall model to a system built over two or three years, you certainly can't for a system of systems built over 50 years: the needs of the enterprise are evolving, the software environment is evolving, the hardware platform is evolving.

What you can do, if you're willing to pay for it, is ruthlessly attack technical debt across your system of systems as a disciplined, on-going activity. Good luck with that.

The 1970 Royce paper was about how waterfall didn't work, and most "Agile" is a subset of DSDM, each flavor missing a necessary thing or two whether working in large systems or growing them greenfield from nothing. But DSDM wasn't "little a" agile (and SAFE just isn't). There is a middle way.

If you like applying this stuff (e.g. you've chatted with Gene Kim, follow Will Larsen, whatever, sure, but you've deliberately iterated your approach based on culture and outcome observability), feel free to drop me a note to user at Google's thing.

Comments on actual blog post: 0

Why are people so afraid to leave replies on the author’s OC

Well, there isn't a formal version of it, because the answer is not formal, it is cultural.

In enterprise software, you have an inherent tension between good software engineering culture, where you follow the Boy Scouts' principle of leaving a codebase cleaner than you found it, and SOC2 compliance requirements that expect every software change to be tracked and approved.

If every kind of clean up requires a ticket, that has to be exhaustively filled out, then wait for a prioritization meeting, then wait for the managers and the bean counters to hem and haw while they contemplate whether or not it's worth it to spend man-hours on non-functional work, then if you're lucky then decide you can spend some time on it three weeks from now and if you're unlucky they decide nope, you gotta learn to work within an imperfect system. After once or twice or trying to work By The Book, most engineers with an ounce of self-respect will decide "fuck it, clearly The System doesn't care," and those with two ounces of self-respect will look for work elsewhere.

Or, you get together with the members of your team and decide, you know what, the program managers and the bean counters, they're not reading any of the code, not doing any of the reviews, and they have no idea how any of this works anyway. So you collectively decide to treat technical debt as the internal concern that it anyway was in the first place - you take an extra half hour, an extra day, however long it takes to put in the extra cleaning or polish, and just tack it on to an existing ticket. You give a little wink and you get a little nod and you help the gears turn a little more smoothly, which is all the stakeholders actually care about anyway.

You cannot replace culture with process. All attempts to replace culture with process will fail. People are not interchangeable cogs in the machine. If you try to treat them as such, they will gum up and get stuck. Ownership and autonomy are the grease that allows the human flywheel to spin freely. That means allowing people to say, "I'm going to do this because I think that it is Right And Good For My System Which I Own", and allowing them to be responsible for the consequences. To pass SOC2, that means treating people like adults and allowing them to sometimes say, instead of "can I get this reviewed because I legit need another set of eyes to take a serious look?", to say "can I get a quick rubber-stamp on this please?"

> The most prevalent one, these days, is that you gradually evolve the complexity over time. You start small and keep adding to it.

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

I doubt many people (if they stop to think about it) actually fit into either of these two schools of thought, they're both extremist positions. It's like claiming that the US population is filled with people believing in either big government autocracy and communism or small government libertarianism and free markets. That's an absurd position to take, just as these opening paragraphs are absurd.

The most generous interpretation is that the author is setting up a strawman.

These are extremist positions. No one except a fool would think that they can design a truly large system from scratch before ever writing a piece of code, and no one but a fool thinks they can write the code for a large system without ever thinking about the design.

The reality is that it sits in between, the author figures this out by the end, fortunately, but wants something they can't have:

> There should be some balanced path in the middle somewhere, but I haven’t stumbled across a formal version of it after all these decades.

First, they at least admit that they're stumbling. That's good, groping around in the dark is not an effective way to find an answer, turn on the lights. You aren't the only one thinking about this subject.

Second, for small projects and simple projects, or rehashes of projects you've done before, the approach often doesn't matter. This only matters for large, complex, and/or novel projects.

Software development is a design process.

Again, in case this was missed: Software development is a design process.

The idea of separating design from development is foolish (BDUF). The idea of separating development from design is equally foolish (extreme take on Agile, see Ron Jeffries failing at sudoku because he tries to use a development technique, TDD, without thinking about the design).

Take the "over 3000 active systems" from paragraph 4. There is no way anyone could have designed all 3000 active systems (either as the 3k systems or in a compressed form) from scratch in a reasonable amount of time. The only reason the author can think of a better design is because they have a design, even if it's not formally documented. The existing software is the design [0] that they can draw from to come up with the better design.

But wait, the foolish BDUF people would not try to refine the system, they'd try and build a new system from scratch. Don't be a fool.

The foolish extreme Agile people would not look at the whole (or a large enough section) and think about refining it, they'd just add to it or change the existing systems.

The sensible person says, "Wait, I acn'

Huh? at least in web, the "big ones" (angular/react/vue/svelte) have been around for YEARS at this point and IMO mostly stablized (though i still don't understand why angular needs to releast a breaking change version every 6-12 months)

the major 'issue' is often near 0 understanding in the fundamentals i'm talking like, super basic, what is an onclick function, how do we get our website to talk to our backend. if you can have clean domain and abstraction cuts, the rest really is a 'technical detail' - i.e. language / framework / technologies truly are all subjective. there are probably combined over 1000 valid tech stacks for a standard "show me table entries in a web dashboard" - not one is 'more correct' or 'more wrong' than the other, but rather in a given _organization_ or with a _given set of devs_ etc. that makes it 'more wrong'. the tech doesn't care, its the team of humans and HOW that team of humans interacts with the stack that is where things can go off the rails

there are so many ways to skin a cat and there ARE tradeoffs (positive AND negative) to each of these tech decisions... i'm not sure what the author is getting at - he seems to hint there are a select few sets of known best practices and tech choices, but fails to list them explicitly... this is dubious at best, and in some way counteracts his claim that it is "incorrect" that tech choices are subjective.

if you want to be non-subjective, be objective. name exactly the tech decisions and best practices you are talking about!