[kjellsbells]

I used to think to this too, but I'm coming around to the idea that it was a useful idea only in the period when software was special, and used by a small number of people, and not extremely ordinary, and ubiquitous.

There's a different kind of high stakes involved when your software is used by (say) scientists in the defense industry to when your software is used by hundreds of thousands of fast food workers at mcdonalds. In the latter case, proficiency is useful but modifiability is not. So then the discussion needs to move to more human factors like discoverability, optimization of the fast path through the users' most frequent operations, and speed.

[crq-yml]

There's a corresponding objection to the idea of fast-food software, though, which is that the world doesn't have to be one-size-fits-all, and in fact we may be near or past a peak era for that approach to software: while everyone still wants and uses manufactured goods, the value chains are increasingly able to incorporate some kind of customization element and deliver services to meet precise definitions.

We know that it's more important to get right answers than fast answers, but the question of whether rightness needs to be shrinkwrapped is inconclusive and subject to the "bundling vs unbundling" innovation dynamic: there are a lot of scenarios where local agency is prioritized, e.g., US ground forces rely on being able to coordinate comms and intel well to achieve objectives within broad parameters, in a bottom-up fashion. That kind of approach does mean there's heavy standardization of specific techniques and technologies, but it's done to enable flexibility in other respects.