Imagine the societal chaos if buildings rerranged themselves without warning or just disappeared ("end-of-support"). We are missing an analytic framework to calculate the economic benefits of stability and costs of pointless change.
I fully agree.
And I truly believe that the world would be a significantly better place if software developers worked for stability and fixing issues, instead of entertaining themselves with "cool" (to their understanding) features or migrations/refactors to new frameworks or languages (and yes, I know these are, sometimes, truly needed). We are way to good at justifying wasted effort and plain "play".
To make this happen, we will need stability-oriented business models and system architectures. E.g. is the business prepared to support multiple generations of SaaS product in parallel, so that customer migration is optional?
For offline software, is maintenance revenue enough to maintain a support team? What happens when most bugs have been fixed and customers stop purchasing maintenance? Is the business prepared to market old versions in parallel with new versions?
Comments
I fully agree.
And I truly believe that the world would be a significantly better place if software developers worked for stability and fixing issues, instead of entertaining themselves with "cool" (to their understanding) features or migrations/refactors to new frameworks or languages (and yes, I know these are, sometimes, truly needed). We are way to good at justifying wasted effort and plain "play".
To make this happen, we will need stability-oriented business models and system architectures. E.g. is the business prepared to support multiple generations of SaaS product in parallel, so that customer migration is optional?
For offline software, is maintenance revenue enough to maintain a support team? What happens when most bugs have been fixed and customers stop purchasing maintenance? Is the business prepared to market old versions in parallel with new versions?