So, a bunch of devs
Either did not see or ignored or put on the back burner something which affected them, even after some prompting. I wonder if these are the same sort of devs who leave security holes in their applications unpatched.
Google this week reversed an overhaul of one of its security-related file formats after the transition broke Android apps. In November, 2021, Google announced changes to the format of its Chrome Certificate Transparency log list file and, in August, 2022, notified developers whose apps might be affected that it would stop …
"bit rot" is real. Unmaintained components eventually stop working, either because (as in this case) some public API it relies on changes, or because it depends on some other library that makes a change (and it didn't constrain the versions for its dependencies properly, or honoring that constraint breaks something else), or because the underlying platform / standard library changes something, and so on and so forth.
While it's certainly true that many end-user-facing "updates" are crap, that tends to be less true for the library components from which that software is assembled. Yeah, you need to test updates (just like any other kind of change) but taking but fixes as they come in is pretty essential. Waiting until you're forced to update some dependency probably means accepting a jump of several versions at once, which makes it harder to track down the problem when something inevitably breaks. And it shouldn't be much work, if you have a proper automated test suite set up. Dependabot (or renovate or any one of a number of other automated tools) opens a PR, you wait for the tests to pass and then you hit the merge button. Easy. But smaller app makers might not have invested in that kind of automated test infrastructure. Writing tests just doesn't feel like it's getting you closer to launching your product (even if basically everyone who's studied it agrees that time spent writing tests pays for itself very quickly...)
"crap improvements' are games adding tokens and hearts and bollocks you can buy with real money.
"crap improvements" are the useful utility suddenly deciding to switch to garish colours, or decide to switch to a subscription model even though you paid for the original.
Another "crap improvement" involves the scrabble game my elderly mother plays which decided to reduce the size of the letters to a size she can't see, and insist on her logging in despite her already paying to remove adverts, and the fact she only ever plays the computer.
saying "bit rot is real" is making the assumption that everything needs to be somehow updated and online. Why the hell can't she play her old game, on her old tablet, which she paid for, and with no internet access required?
There is tried and tested software running on mainframes etc. that has been stable for decades, but these days, everyone wants to change things all the time, usually because their low quality code is full of bugs, or for the next shiny-shiny.
What happened to proper testing, and proper thought out design?
Why does MS have a new version of a word processor or spreadsheet program every year? You must be younger than 40. You don't know a time where developers weren't amateurs or cowboys!
Live by third-party components, die by third-party components.
Now that a great deal of software development has moved to just composing things out of huge numbers of third-party components of uncertain provenance, quality, and maintenance, stories like this one will quickly become so commonplace that they won't be newsworthy. It will just be software breaking all the time.
You might have thought something as ridiculous as the left-pad debacle would have woken ISVs up about the dangers of letting their devs just pull in thousands of dependencies from package repositories, but no. Short-term economic incentives dominate the market.
"all old software"
Not if it encapsulates its data properly in an OO sense. But if you interoperate with external data feeds and they jump to the next rev, you had better as well. Or hope that the designers of the new version saw fit to provide utilities that trsnslate between new and old.
"The impact on our business is huge," said the person who owned a company that not only ignored the deprecation warnings, failed to apply the PR that was *right there* to fix in the library they were using.
They didn't even have to do the dev work.. fork, apply PR, use that until mainline catches up. 10 minutes work - done it dozens of times.
If they they didn't want to make any effort. That's on them.