Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systems Thinking

theprogrammersparadox.blogspot.com

Post reply on HN
Print view View original

21–30 of 123 posts

Re: Systems Thinking

#21

Post by iafan »

_dark_matter_ wrote: post #20
iafan wrote: post #13

> There are two main schools of thought in software development about how to build really big, complicated stuff. > 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 interestin…

Iceberg is, primarily, a spec [0]. It defines exactly what data is stored and how it is interacted with. The community debates broadly on spec changes first, see a recent one on cross-platform SQL UDFs [1]. We have yet to see a largely llm driven language implementation, but it is surely possible. I imagine it would be easier to tell the llm to instead translate the Java implementation to whatever language you need.…

If I had a spec for something non-trivial, I probably would ask AI to create a test suite first. Or port tests from an existing system since each test is typically orders of magnitude easier to rewrite in any language, and then run AI in a loop until the tests pass.

Re: Systems Thinking

#22

Post by zppln »

readthenotes1 wrote: post #2

A major factor supporting evolution over big up-front design is the drift in system requirements over time. Even on large military like projects, apparently there's "discovery"--and the more years that pass, the more requirements change.

This isn't my experience. Requirements tend to settle over time (unless they're stupidly written). Users tend to like things to stay the same, with perhaps some improvement to performance here and there.

But if anything, all development is the search for the search for the requirements. Some just value writing them down.

Re: Systems Thinking

#24

Post by fc417fc802 »

iafan wrote: post #13

> There are two main schools of thought in software development about how to build really big, complicated stuff. > 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 interestin…

There are parallels of thought here to template and macro libraries.

One issue is that a spec without a working reference implementation is essentially the same as a pull request that's never been successfully compiled. Generalization is good but you can't get away from actually doing the thing at the end of the day.

I've run into this issue with C++ templates before. Throw a type at a template that it hasn't previously been tested with and it can fall apart in new and exciting ways.

Re: Systems Thinking

#25

Post by codeflo »

bestham wrote: post #3

“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

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.

Re: Systems Thinking

#26

Post by zkmon »

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

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.

Re: Systems Thinking

#27

Post by jackblemming »

bestham wrote: post #3

“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

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

Re: Systems Thinking

#28

Post by iafan »

praptak wrote: post #23

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

Everything that is touching hardware, for example. Bluetooth stack, HDMI, you name it.

Everything W3C does. Go is evolving through specs first. Probably every other programming language these days.

People already do that for humankind-scale projects where there have to be multiple implementations that can talk to each other. Iteration is inevitable for anything that gains traction, but it still can be iteration on specs first rather than on code.

Re: Systems Thinking

#29

Post by polyglotfacto »

iafan wrote: post #13

> There are two main schools of thought in software development about how to build really big, complicated stuff. > 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 interestin…

You can look at the Web as a starter: https://html.spec.whatwg.org/#history-2

> The WHATWG was based on several core principles, (..) and that specifications need to be detailed enough that implementations can achieve complete interoperability without reverse-engineering each other.

But in my experience you need more than a spec, because an implementation is not just something that implements a spec, it is also the result of making many architectural choices in how the spec is implemented.

Also even with detailed specs AI still needs additional guidance. For example couple of weeks ago Cursor unleashed thousands of agents with access to web standards and the shared WPT test suite: the result was total nonsense.

So the future might rather be like a Russian doll of specs: start with a high-level system description, and then support it with finer-grained specs of parts of the system. This could go down all the way to the code itself: existing architectural patterns provide a spec for how to code a feature that is just a variation of such a pattern. Then whenever your system needs to do something new, you have to provide the code patterns for it. The AI is then relegated to its strength: applying existing patterns.

TLA+ has a concept of refinement, which is kind of what I described above as Russian dolls but only applied to TLA+ specs.

Here is a quote that describes the idea:

There is no fundamental distinction between specifications and implementations. We simply have specifications, some of which implement other specifications. A Java program can be viewed as a specification of a JVM (Java Virtual Machine) program, which can be viewed as a specification of an assembly language program, which can be viewed as a specification of an execution of the computer's machine instructions, which can be viewed as a specification of an execution of its register-transfer level design, and so on.

Source: https://cseweb.ucsd.edu/classes/sp05/cse128/ (chapter 1, last page)

Re: Systems Thinking

#30

Post by nasretdinov »

bestham wrote: post #3

“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

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).
Post reply on HN