He does allude to it about faster software (slow being equated with buggy), and I think there are market indications that for specific markets, fast (efficient software) does win--though it is the exception seemingly, rather than the rule. The rule seems to be quick-to-market software wins.
However, I think his point has a wider scope, and I don't think it's irrelevant. Yes, in the short term, market forces push us to put software in front of people quickly, even if it's buggy. But is that beneficial in the long term? What would be the consequences of making short term optimal choices here?
Would we (as a society) forget how to build the things we rely upon in our society because the complexity is too overwhelming, and at every step, we never went back to clean things up and focus on transferring inter-generational knowledge, because we were too busy putting out features?
Just like in the Innovator's Dilemma, the incumbent at every step makes the optimal decision, but ends up getting trounced because a series of local optimized choices is not a globally optimized choice. And Blow here is saying (strongly), that we're doing something similar with how we build software.
And I'm inclined to agree with him, even though I fully recognize the market forces as being strong. Would we keep making short-term optimal choices because we have no choice? Or is there a way out?
Alan Kay has talked about this in some of his talks. He has some neat ideas, wrapped up in unintelligible slides. I've always thought he needs a graphic designer for his slides. Anyway, his thesis is that we build software today much like how Egyptians built buildings: stacking things wide in order to build high--evident by code bases millions of lines long. We have very few equivalent of arches in software. Once we had arches, we could build higher with less materials.
So perhaps there's a way out. We've been searching for it for a long time (in software years, but we're still a young field), ever since before the Mythical Man Month. And Blow, I think, is saying, there are real consequences to this software mess we find ourselves in, the worst of which is the collapse of civ itself, esp if we don't find a way to reign in the complexity and the bugginess.
Or we can pray for AGI to get done and do it all for us. finger guns
The exact same argument we can use to describe why inefficient software tends to win can be used to describe why buggy software tends to win.
Of course users hate bugs. But even more they hate not having software to solve their problems. Hands down I would choose to have something with bugs today, than wait for something bug-free 6 or 12 months from now.
And unfortunately, once you put something with bugs in front of users, you're going to be pushed to work on new features for the next version, rather than fixing the bugs of the previous version. But arguably that's irrelevant! Users would rather have those future new features in 3 months, over having all their bugs fixed in 6 months, and then getting those new features in 12 months.
It still feels incredibly annoying and lame to me that this is the state of things. And I think that's why people like Jonathan Blow (and many, many others) just don't get it. Working software in users' hands trumps everything else. It almost doesn't matter how inefficient or buggy or $OTHER_NEGATIVE_TRAIT it is. If it solves unsolved problems, then it wins.
[Yes, I know, there are limits to what users will tolerate. But most inefficient, buggy software doesn't hit those limits too often. Software that does... well, yep, they tend to fail. But they're quickly replaced by other inefficient, buggy software that users will tolerate. They're not replaced by super-efficient, nearly-bug-free software, because building that software will always take much longer than building the software that users will tolerate. And users want to get shit done, not wait around while you tell them how much better the efficient, nearly-bug-free software will be.