Hacker News Reader

Comment by gitgacutils | Hacker News Reader

> If you write code on .NET, you should adopt this release ASAP.

If you require the new features maybe, but if you are writing enterprise code, you shouldn't rush into things.

> Doubly so if you care about runtime performance.

Everyone cares about runtime performance, but if your software isn't experiencing performance issues, there is no need to rush into things. Or at the very least, reach out to your clients to get a feel about their schedules and expectations.

#1 rule: if it ain't broke, don't fix it.

View on HN

Having a proper test suite and updating when the changes are minimal usually leads to better overall product maintenance.

I dont get these claims to not upgrade unless you're also just as worried about changing a line of code and having it all break too? Make the changes, test the changes, and deploy carefully, just as you would for anything else.

I don't think he was suggesting anyone rush into anything. At the same time, a lot of "enterprise" software is still running on Java versions from over a decade ago, so perhaps they'd benefit if they had someone rushing them.

You are very correct, I'll try to temper my enthusiasm.

This is why I can't work in enterprise.

Smart man. Enterprise Dev/Arch here ;)

This is how legacy code is created isn't it?

What is wrong with legacy code? Isn't every code that is deployed to production legacy? Because you cannot just change it.

There are lots of ways you can end up with legacy code.

I've seen legacy code get created by people postponing platform updates for so long that the upgrade pathways stop being supported, that's one way.

I've also seen legacy code get created by people adopting the platform of the future super-early, and then being left high and dry when the rest of the world decided that platform wasn't actually the future after all, leaving them as the sole maintainers of the entire platform as well as their dependent code.

If your code currently works on standard .net, there's no reason to be in a massive hurry to move to .net core. There's not necessarily any reason to delay, either. It all depends on your business requirements and the investment required. If it's easy for you to move to .net core then by all means do it. If it's gonna be a massive project, let the smaller groups go first.

> I've seen legacy code get created by people postponing platform updates for so long that the upgrade pathways stop being supported, that's one way.

This is something i've seen many times, when you don't update in long enough entire API's might've changed or been replaced and there's no documentation or anyone even remembering the stuff available anymore.

I agree though that one doesn't have to rush new releases, i do however think there should be a plan to upgrade done as soon as there's a new stable release.

I've been working with a softphone that's built for .net framework 3.5, if you want any library you can forget nuget, must get source build and modify manually. Which is suboptimal.

Reply on news.ycombinator.com