|
|
|
|
|
by polskibus
2507 days ago
|
|
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. |
|
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.