[devonkim]

This sounds like you're talking about abstracting and decoupling components. Building systems to accommodate heterogeneous environments early is akin to starting a project with microservices instead of a monolith - it's overscoping probably. Furthermore, it's fallacious to say that all software should fit some new standards of environments when there's no scenario for it all (the COBOL code that's for accounting doesn't have anything to do with the products your company sells probably).

This then raises issues of compatibility with your customer's environments. The configuration matrix that you'd need to test is tedious (read: costly) in traditional software releases compared to SaaS where you're free to make a lot of decisions independent of your customer and not everything can be automated (anyone that's deployed automated tests against TN3270 terminals with a lukewarm IQ QA department is right to challenge this). Then there's longevity. What happens when your biggest paying customer wants you to stay on IE 8 until 2025 (not an exaggeration)? Want to create yet another customer-specific branch? Eventually you wind up needing a test environment that matches exactly what that customer has and paying contractors to maintain that dead-end tech stack and doing that for every customer. That is quite common and also quite costly but not needing much talent, so the washed up maintenance engineers go here at less than mediocre compensation to cut costs. That's zombie software for you - the soul and spirit of engineers are gone and its corpse is animated by money by a cruel master that cares little for its past life.