Things in the physical world break down beacuse they are made of matter, and the entire concept of "working" is a very simplified modeling of their behaviour that doesn't include second-order effects like tear,consumption of materials etc.
Code, on the other hand, is a social constrution but entirely confined in an abstract and mathematical world. The _only_ reason we still don't have a reliable and solid code infrastructure (in the sense explained by the article) is our inability as a community to once and for all define a solid foundation for the principles of computing. Hence all the hacked together languages, tools and frameworks that people have piled on each other over the decades.
If one century of efforts hasn't been enough, fine. But we absolutely can work towards that goal.
Brian Cantrill had a good observation in a 2007 Google TechTalk introducing Dtrace:
> In software the blueprints are the machine. In software once you design the thing you've built it: the design is the machine. That's why the waterfall model is so fundamentally flawed. This idea that you could design the design before you design it, which is what the waterfall model is essentially saying, is flawed. Software is both, it's both information and machine. (@3m40s)
* https://www.youtube.com/watch?v=6chLw2aodYQ
I originally ran across it on Google Video:
* http://video.google.com/videoplay?docid=-8002801113289007228
Social constructs are not immutable any more than physical ones. They're more likely to change, from what I've seen.
Making software is about groups of people interacting, side effects of the software, and lossy interfaces more than it is about mathematics.
Hardware standards shift because of an Apple PR camopaign. We stopped using zeppelins only after one disaster of several dozens made very public by live radio coverage. Non-Sufficiently standardized rockets explode because countries can't pick a measurement system. The auto industry in a country changes overnight because a dictator decides that the roadside to travel on shall be switched on a whim.
Just like software, infrastructure/hardware/whatever is an unfathomably complex web made from science, faith, half-knowledge, geopolitics, coincidences, rules, dick moves, physics and random tweets.
I don't think we are winning anything by trying to lift software onto some kind of pedestal of specialness in every regard...
Is this possible? If code is a social construction as you say, then wouldn't it be impossible to arrive at this point unless society remains unchanging?
> Hence all the hacked together languages, tools and frameworks that people have piled on each other over the decades.
This hints at the what is IMO the real problem, software is hard to replace with confidence. Sure, it's easy to swap one version for another, but doing so with the full understanding of what will change...is basically impossible for any non-toy project today. And there are exceptions to this, but they're the "exception that proves the rule" type.
I can't remember the link but you can probably find something. the way they code is very careful and deliberate. everyone has an office, none of this "rockstar" nonsense that you have at startups, they are all serious people, the deadlines are sensible, no one pulls all nighters, they come in at 9 and get out at 5. absolutely nothing gets written without documenting it. no line of gets changed without the reason for the change written in documentation. everything is carefully panned. needless to say the code got the ship to the moon and back. this is how coding should be done
Just look at the Windows Internals books to understand the complexity of just the systems in the operating system. It isn't something that needs to be "fixed" just because something is complex.
Everything is more complex than we think it is, and that's not really a problem.
Similarly, "Functions as a Service" makes many problems the hosting provider's problem. All of the low level goop is theirs. You still have OP's problems but the responsibility surface is reduced.
It's more like "you now have to deal with different problems" much more than it is "you have to deal with less problems". Maybe the problem quantity got reduced from 1000+ to 50+ but the latter might swallow much more time to solve so it's really questionable which of both is better.
Cars are not a good example to point to. The thing that would make cars a good example would be if cars were shown to exhibit a steady increase in essential complexity. In that case, yes, we might point to them and say, "Maybe the situation for software is the same, and we're mistaken to have any unreasonable expectations to the contrary?" But that doesn't match reality. Car manufacturers are as guilty as software developers of producing things that have gotten steadily complex without good engineering reasons to justify the complexification.
(Pre-emptive request: please do not respond to this comment as if I'm arguing that cars have not become safer or more fuel efficient.)
As for the mechanical components of the car - the modern Bug is a diesel (non-PD) so has a common rail fuel system. I can read fault codes with the OBD2 mechanism but not everything is accessible.
Both tremendous fun but the modern one is 100 times more complex and I would struggle to maintain it single-handedly. But I don't feel the need to reduce the modern car or "fix" the issue of its complexity simply because it is more complex.
My wife has a Mini that has developed a fault but who knows what sensor has failed according to the OBD2 codes?! I don't feel the need to "fix" that and reduce it to the old 1991 Mini Cooper I had (which had its own set of baffling problems, like in-line fuses for important things like the injector but a fuse box for non-essential things like the interior light..... but that's another story).
https://www.strongtowns.org/the-growth-ponzi-scheme
But I think the initial-to-maintenance ratio of software is both different than for physical infrastructure, but also perhaps more importantly, very different than many decision-makers expect.
Hyperbolic titles are indeed a problem of our age though, I agree on that completely. But your prejudice towards programmers who are supposedly thinking their problems are novel and unexpected is not justified.
That sounds a bit broad. In the general aviation world, engine designs from the 60's are still in widespread use.
As is leaded fuel, to the delight off everyone living within a few miles of airports. Old can be good, until it's not anymore. There's often survivorship bias involved as the worst--or unadaptable--designs have naturally fallen out of use or been supplanted.
You can use designs from the 60s today and the result will be a brand new system that in time will rot away and need to be replaced by, possibly the same design. That doesn't invalidate what he is talking about.
Even the pyramids of Giza will eventually rot away given time.
The difference in software, in my opinion, is speed in which change occurs.