I would say that this blog post is half right. The half that's not right is glaring.
> the pyramids have had 100% up-time with no human maintenance
It helps that there is hardly any rain in the desert. Water would foul up the structure in a matter of years.
> dependencies are added like seasoning. Hundreds of packages. Thousands of foreign lines of code make their way onto your software routinely
True, and I think NPM JavaScript exhibits the worst of this behavior.
> Problems are expected and fixed on the fly, somewhat haphazardly: ... push a patch ... code scanning ... dependa-bot ... DevOps
True, and I remember when software releases were treated with much more care and quality because it costs a lot to ship a CD or game cartridge rather than a download.
> More waterfall-y.
That's not a good thing. Having a short feedback cycle from implementation back to design is a big win for software development. Waterfall is the dark ages when we didn't know better.
> This is where minimalist software is built.
Agreed.
> No build process
That doesn't make any sense, unless you're writing machine code directly in hexadecimal.
> no outside dependencies
I agree with minimizing dependencies, but there's no such thing as no dependencies. I dare you to avoid any of these libraries: HTTP (especially HTTP/2 and 3 which are much harder than HTTP/1), TLS/SSL, TCP/IP, hardware drivers, compilers, data codecs like DEFLATE, multimedia codecs like AVC and AAC.
> There's no need to be constantly refactoring things, since everything was designed up to spec beforehand. ... The catch? Writing such a spec costs you over 80% of your engineering time, and you'll have nothing to show for it until day 100.
This is a fallacy. I agree with and like this talk where the speaker Glenn Vanderburg argues that the software is the specification, the construction is done by compilers, and that most analogies to physical engineering are completely wrong. https://www.youtube.com/watch?v=NP9AIUT9nos
> The thing is, most humans are laughably bad at architecting software without actually writing it first.
There's no shame in discovering the software architecture as you go along. If you already knew the architecture beforehand, that means you're very familiar with the problem space already, and you probably should've written a framework to avoid repetitive work. In a sense, software development biases toward novel exploratory work rather than routine work, and that's why it's challenging.
> this all stems from a certain greed software developers have ... Meanwhile other engineering fields are far more humble.
Nonsense; greed is human. In all fields of engineering, the general principle is to do more with less. As the saying goes, any fool can build a bridge, but only an engineer can build a bridge that barely stands. All engineers want more features for less cost, and software is no different. The difference is that in most engineering, there are more physical constraints, more templates to apply, more repetitive work. And because of that, the norms are well-established in traditional engineering. You don't look at a big McMansion and call it "greedy" because it's just the norm. You don't look at a sprawling highway interchange with 4 levels of ramps and call it "greedy" because it's socially acceptable.
> Even your measly human body doesn't need weekly patches
Have you looked at the list of bugs for humans? Allergies, back pain, appendix, aging, various birth defects, cancer, etc. If anything, life is the ultimate example of spaghetti coding and monkey-patching. Look at how vertebrate embryos (human, chicken, fish) all look the same in the first few weeks of life, then they diverge as various body parts and limbs are grown or shrunken.
> Sadly, a good home-cooked meal is hard to find nowadays. Fast food is just too good to beat.
It's weird when people praise home-cooked meals, because I've found restaurants that have great food. Heck, I've been to various traditional sit-down restaurants where they bring you the food in one minute and is faster than standing in line at McDonald's.
> Most software today just feels bloated and trashy, even if the experience is drug-like.
Most software do feel bloated and trashy to me too. I especially find that the more popular a software is, the trashier it is. A few decades ago for example, I found MSN Messenger to be popular but insufferable (big program size, laggy UI, lots of attention-grabbing features) whereas IRC was an underground community and the software was very well-behaved (small, not attention-grabbing).
Overall, I agree with the ideas that simpler software is better, there's too much cargo-culting in industry, piling on complexity and dependencies is bad. But your article wanders all over the place and doesn't hit the right points.