Sure, there's an extreme on both ends. The problem you're describing is that the upgrades suggested were probably not frictionless, managers were burnt before by needless upgrades that took too much resources for little value. If tech companies took much more care wrt upgrades and not breaking stuff, then users of the tech would not see upgrades as needlessly risky.
An example of this is net core vs net fx. Net core broke many things, has not implemented full compatibility from day one, introduced netstandard , which as of latest version is not implemented by netfx, introduced new toolset (dotnet) aside msbuild (bear in mind that VS still uses Ms uild) and so on.
This is all a matter of incentives both for tech companies and for their workers - they are often rewarded for short term/easy to see by managers impact, not for bugfixing, stability or long term support. It was not always like this - in the 90s MS would be picked because they took care to not break stuff. Migrating .Net 1.1 to 2.0 was super easy.
There is always going to be major flux as new architectures are evolved until they are stable. If this was hidden, there would have been little input from outside Microsoft.
While there have been legitimate problems with this process - for example, the explicit ‘go live’ given by Microsoft before things were truly stable, there was a choice made to develop in public and the net result (sorry) seems positive to me.
Depends on the success metric. If you look at the cost of the tech churn to the businesses that have to spend much more than before to achieve similar results as before, then it is not positive result to anyone but tech providers, and (young) developers that are needed to redevelop. I wonder how much will businesses tolerate this if promised efficiency gains do not materialize for most of them.
> I wonder how much will businesses tolerate this if promised efficiency gains do not materialize for most of them.
I think you've stumbled on the core issue here. For an unchanging company for which their digital business does not need to evolve very much, having a basic IT department may just work. But as we digitize more and make technology a core competency and critical differentiator, a legacy, inflexible tech stack becomes a burden. It doesn't let you add the features that your customers may want, features which might be critical to a continuing and successful business relationship. Your customers then have similar demands from _their_ customers... all the way back to the primary sector.
An example of this is net core vs net fx. Net core broke many things, has not implemented full compatibility from day one, introduced netstandard , which as of latest version is not implemented by netfx, introduced new toolset (dotnet) aside msbuild (bear in mind that VS still uses Ms uild) and so on.
This is all a matter of incentives both for tech companies and for their workers - they are often rewarded for short term/easy to see by managers impact, not for bugfixing, stability or long term support. It was not always like this - in the 90s MS would be picked because they took care to not break stuff. Migrating .Net 1.1 to 2.0 was super easy.