To me, the issue seems to be shared in common with "hard" engineering and infrastructure - it's easier to build than to maintain. The demo is easy, the thing pe

To me, the issue seems to be shared in common with "hard" engineering and infrastructure - it's easier to build than to maintain. The demo is easy, the thing people count on for their own work is a Sisyphean monstrosity. The difference is just one of speed and scale. The software starts paying for maintenance almost immediately. People see a open source codebase that is now "good enough" for their problem, and within months it becomes a popular dependency, and then a singularity. Construction that goes wrong, on the other hand, often has a narrative that plays out over decades. The featureset of a bridge or building grows little with time, and often slims down, and so while the maintenance can be physically costly, it isn't like the building gets remodelled and rewired each year to do a new thing, which is a thing that happens often to software. Software companies that can really embrace the "maintenance of a singularity" role usually last, even if they accrue some tremendous technical debt: see Microsoft, Oracle, Adobe for some examples. Companies that try to elude that outcome, on the other hand, have to have a business model of disposability: Apple tends to obsolete software when new hardware hits, as do most game companies. The companies that let the product rot are the common failure case, and the companies that keep the product small are themselves small.