Hacker News Reader

Comment by userbinator | Hacker News Reader

I wish more developers would abide by the old saying "don't fix it if it ain't broke." It's one thing to update because you know a newer version has fixed a bug you're experiencing, but if everything is already working as you'd expect, IMHO you're just asking for trouble. There's a reason a lot of the infrastructure systems that many people don't even know about --- until something breaks --- hasn't changed in literally decades.

(Of course, "everything is working" might not be true, in which case you could be trading one bug for some others. But the sad state of "modern" software development is a rant I won't go into here...)

View on HN

The problem is the technical debt you acquire this way.

Eventually you're going to need to upgrade X for a security fix, but the new version of X isn't compatible with the version of Y you are using, and upgrading that would break Z, and Z would break your app here and here. Now you're spending a couple weeks trying to do the upgrade to get a security fix that was 0 day two weeks ago, when you should have been writing things that actually advanced your app instead.

I keep my dependencies up to date, and consider it technical debt when they are not, and would never want to go back.

I agree on one hand, but on the other if you take this approach, eventually the number of changes will be enormous and the cause of any issue that crops up may be that much harder to pin point. If you keep somewhat up to date, it's smaller challenges each time.

I suppose if they'd done the update into a test environment like a regular release then it's far more likely these issues would've come out there and it wouldn't have been so stressful.

You are asking for security issues if you take this approach. Better to increment on several small iterations of dependencies, making changes accordingly, such that you will be able to take a CVE-fixing patch without having to refactor your entire app all at once.

Introducing changes to the semantics of query operators in minor releases sounds like a great way to introduce security issues.

How many CVEs over the years are because of someone screwing up their operator precedence in permissions checks?

yes that's true, but the bigger the set of changes between your application and the current version of dependencies, the more likely you'll have a serious issue if you are eventually forced to upgrade

the best change is no change, the second best change is a small change

> I wish more developers would abide by the old saying "don't fix it if it ain't broke."

This can work for internal software (see people still running old Windows and IE for some random internal app), but breaks down for software with public access. The problem is when a bug is found, and one will be found, the farther behind the current release you are, the harder it is likely to fix.

I prefer to update my dependencies every so often so that I'm never too far behind if I'm suddenly forced to update for some critical security issue.

Unfortunately if you don't update the packages your app depends on, you don't gain access to the newer conveniences & improvements (security, performance, etc) that have been introduced.

Reply on news.ycombinator.com