A Note on Essential Complexity
olano.dev
A Note on Essential Complexity
1–10 of 51 posts
Re: A Note on Essential Complexity
#2Humans simply cannot keep the whole stack for a complex system in memory, that is why we abstract layers with APIs etc and generally specialize on one layer only.
My (Sci-Fi) book postulated that an AGI (a real AGI, after all it was Sci-Fi) would simply discard everything the humans wrote and rewrite the complete stack (including later on the Hardware and ISA) in machine code without anything unnecessary for the task and of course totally unreadable to a human. It is an interesting scenario to ponder.
Re: A Note on Essential Complexity
#3Humans simply cannot keep the whole stack for a complex system in memory, that is why we abstract layers with APIs etc and generally specialize on one layer only. My (Sci-Fi) book postulated that an AGI (a real AGI, after all it was Sci-Fi) would simply discard everything the humans wrote and rewrite the complete stack (including later on the Hardware and ISA) in machine code without anything unnecessary for the task…
OTOH a lot of the abstractions are created because problems aren't solved coherently but rather partitioned into organizational structures adding incidental complexity. The worst are -services that seem to always do too much/too little or have interface designs that suit itself than needs of clients/consumers. I spend a fair amount of time decomplexifying the org out of architectures when we realize that performance sucks because reasons.
We can do a lot of that discarding of excess by realizing that there's the data that's read, the rules applied, and the data that's written. Everything else is ephemeral and plumbing. Looking at a process that way, and seeing the amount of complexity/abstractions one can ask what all that really necessary? Does it pay for itself in some way? It has to justify its existence beyond implementing the needed process.
I question the value of frameworks sometimes[0].
[0] https://ptrthomas.wordpress.com/2006/06/06/java-call-stack-f...
Re: A Note on Essential Complexity
#4A well-written article. On a similar theme of essential vs. accidental complexity: FWIW, I summarised a talk gave by Paolo Bonzini (a Linux/KVM/QEMU maintainer) here in the past:
https://lwn.net/Articles/872321/ -- A QEMU case study in grappling with software complexity
Although it was in context of QEMU, the lessons from it can be applied to many other projects.
Re: A Note on Essential Complexity
#5Humans simply cannot keep the whole stack for a complex system in memory, that is why we abstract layers with APIs etc and generally specialize on one layer only. My (Sci-Fi) book postulated that an AGI (a real AGI, after all it was Sci-Fi) would simply discard everything the humans wrote and rewrite the complete stack (including later on the Hardware and ISA) in machine code without anything unnecessary for the task…
While AIs are able to keep more in their “mind” at the same time than humans, there is still a cost to consider (e.g. token limit). If software requires more effort to change (adding a feature, fixing a bug) due to spaghetti architecture, then that will also add to the cost.
Secondly, we may want to keep software on a complexity level understandable by humans, in order to not become completely dependent on the software engineering AIs.
Thirdly, the same effect that we observe with software written by humans getting to complex to understand by any human, is likely to also occur with AIs of any given capacity. AIs will have to take care, just like humans have to, that the complexity doesn’t grow to exceed their abilities to maintain the software. The old adage “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.” probably also applies to AIs.
The essential complexity of software doesn’t depend on whether a human or an AI writes it. AIs may be able to handle more accidental complexity, but it’s unclear if that is an actual benefit under the cost arguments mentioned above. So maybe it will only be useful to create and maintain software with more essential complexity than humans can handle. The question is if we want to depend on such software.
Re: A Note on Essential Complexity
#6Humans simply cannot keep the whole stack for a complex system in memory, that is why we abstract layers with APIs etc and generally specialize on one layer only. My (Sci-Fi) book postulated that an AGI (a real AGI, after all it was Sci-Fi) would simply discard everything the humans wrote and rewrite the complete stack (including later on the Hardware and ISA) in machine code without anything unnecessary for the task…
I checked out your book link https://rodyne.com/?p=1252 >, is there a preview chapter or two somewhere? That's cool you wrote a compelling sci-fi but my list is competitive :)
Re: A Note on Essential Complexity
#7I feel like this article over-complicates things by using a strange definition of “essential complexity”: That if a user says that something is necessary, than that is essential complexity.
Personally I never assume that the user has distilled a problem down to its essence. Regardless, my process looks a lot like what the author recommends: Question assumptions, propose alternatives, eliminate work, etc.
Re: A Note on Essential Complexity
#8I feel like this article over-complicates things by using a strange definition of “essential complexity”: That if a user says that something is necessary, than that is essential complexity. Personally I never assume that the user has distilled a problem down to its essence. Regardless, my process looks a lot like what the author recommends: Question assumptions, propose alternatives, eliminate work, etc.
This is addressed in the second half of the article
> Strictly following Moseley and Marks’s definition, the fact that we can get the user (or the customer, or the product owner) to accept a change of requirements, implies that the removed complexity wasn’t essential in the first place.
Re: A Note on Essential Complexity
#9I feel like this article over-complicates things by using a strange definition of “essential complexity”: That if a user says that something is necessary, than that is essential complexity. Personally I never assume that the user has distilled a problem down to its essence. Regardless, my process looks a lot like what the author recommends: Question assumptions, propose alternatives, eliminate work, etc.
This is addressed in the second half of the article > Strictly following Moseley and Marks’s definition, the fact that we can get the user (or the customer, or the product owner) to accept a change of requirements, implies that the removed complexity wasn’t essential in the first place.
Let me editorialize that:
> Strictly following Mosley and Marks’s different definition because it’s strange and I can easily poke holes in it…
Again, I’m not sure why it was necessary to “strictly follow” that bizarre definition of essential complexity, one that seems to define anything a user says as “essential”.
Re: A Note on Essential Complexity
#10Left to their own devices, software engineers would act as the philosophical razor, removing the complexity of the world; automating employees —the engineers themselves included— out of a job; simplifying systems, along with the organizations that own them, out of existence.
A lot of people I've worked with appear to have realised that and taken it to the other extreme --- for them, complexity is what keeps them employed, so they find other excuses for justifying its (and their) existence and continue taking the abstractions beyond 11. Some communities/languages like Enterprise Java and .NET are an example of that; and more recently, JS. The old Stroustrup C++ satire also comes to mind.