So while I have some issues with this as a generalization (because I think the reality is more diverse):
> Because the way software tools work and the way software is written is that it is all completely optimized for short-term business goals and results.
—let's assume it now for the sake of argument. What's still weak in the thesis imo is the connection from your proposed better way of approaching software development to longer-term business goals. For instance, I think one possibility is that the typical state of affairs, over a longer time-span, is that what the software itself should even be, what it needs to accomplish, which systems it interacts with etc., is volatile enough that in most cases (there are very important exceptions of course), businesses would do better long term by optimizing for flexibility in changing even the spec for the software, vs devoting more resources to ensuring any individual representation of a software concept is particularly durable.
What I'd want to know next on the matter is what evidence exists for the likelihood of one stance over the other being correct. Are there examples of extraordinary long-term success from companies whose approach to development went in the direction of durability (I'll say as an approximation)? Is it a common occurrence for companies to succeed short-term by making sacrifices in quality, and then to fail longer-term specifically because of their over-complex / incoherent, buggy software (or is that more of an exceptional case)?
I don't think we have great ways of encoding domain knowledge, let alone turn it into software (and I wonder if we ever will). Encoding domain knowledge is mostly about human to human communication, and there is some value in using programs as a communication medium, but I think transferring and extending domain knowledge is primarily a human process (meetings, documentation, strategy documents, etc..) that software would actually slow down.
I honestly find today's software quite fantastic. I don't know what tree Jonathan Blow is climbing, but compared to the 80ies, it is unbelievably easy to find good code, good books, just an infinity of resources on every aspect of software you would like to target, from the intricacies of whatever pipelines your CPU has to large scale distributed systems to pragmatic product thinking in software architecture. When I started programming, I was lucky to find Abrash's book about performance, and... that was it. Nowadays, not only are there a million videos on youtube, but I can literally look at the internals of most advanced optimizing compilers under the sun, and have direct access to all the published academic research on the same topics.
In fact, the reason so many people can just grab javascript and create a full webapp in a couple of days is because so much amazing work is being done on low-level optimization. Not only that, but proper software engineering technique that were hit or miss even just 10 years ago are common in even the smallest javascript projects (source control, versioning, CICD, unit tests, automatic linting and analysis, packaging, often solid collaborative development guidelines).
I regularly switch between counting cycles in baremetal embedded and writing e-commerce javascript and PHP applications. In embedded my metric is writing tight software (because tight means cheaper chip), in the other, my metric is to make a retail business successful, and software is but a tiny part of that. 1I literally do not care that my whatever analytics job running overnight takes 2h when I could optimize it down to 30 seconds, because as funny as it sounds, tweaking the CSS of the email banner or handling proper retina ad-banners is a much more relevant problem.
Seeing the amount of talented and dedicated people working in software, I can't but think of Jonathan Blow as someone who is deeply incurious and small-minded: he cannot fathom what richness is out there, and assumes that other people wouldn't be able to leverage said richness either.
I'm glad he is a successful indie game developer, but that is not the high horse to ride on he thinks it is.
I'm not sure that's entirely true. It ostensibly is, but the way it is written is not optimized for long-term business goals. Because the way software tools work and the way software is written is that it is all completely optimized for short-term business goals and results.
I'm trying to pen an article that addresses this, because software is often if not solely viewed as just doing something, when that's only a component of what it does. If we additionally view it as a way to communicate amongst humans and a way to think about and encode a domain, then we begin to see the failings of software in today's world. In this holistic viewpoint, software is best viewed as stored and interactive knowledge. If software is simply viewed as a way to do something, then the stored knowledge becomes highly implicit and incomplete, and a communication breakdown happens. Viewing things with this lens, it is no surprise why today's software is primarily towers of shit. There is no handling of variety, that is complexity, because the way to handle it is to properly communicate within the medium of software systems and encode the domain. Otherwise, software just doing something often creates more complexity than it reduces.