Backwards compatibility

I feel like there’s a worrying trend in some parts of the IT industry which needs to be called out.

If I take a piece of Java code from five or ten years ago and fire it up on today’s JVM (let’s say 11 or 17), will it still work?

Not necessarily - Java 11, in particular, dropped certain packages from the standard library which you now have to reinstate or set flags to resurrect.

But the fact remains that (in my experience) it would only take a few hours’ faffing to stand that piece of code back up. For sure, it might be relying on some big framework which is now a major version out of date, leaving you with a non-trivial upgrade job. But building and running what you’ve got should be reasonably painless. You then at least have the choice of when to tackle the upgrade, or if you just want to get in, make tweaks and get out.

Compare and contrast this with some of the “modern stuff” that’s around these days. My particular bugbear is any sort of modern Javascript - it feels like both the languages and the frameworks evolve (read: change their minds) so rapidly that something which was bang up to date as recently as 2017 suddenly needs a lot of hours sinking into getting it maintainable and using the same metaphors and libraries as more recent code.

Perhaps it’s a sign of me getting old and grumpy, but I hate this.

If there’s one thing Microsoft got right - and still gets right today - it’s backwards compatibility. You can take that creaky 1995 exe file for controlling an HVAC system, and with a few clicks, it almost certainly still works on your Windows 11 laptop today.

That comes at a cost, for sure, but I am determined to teach my team that backwards compatibility is something worth striving for. Meanwhile, let’s hope Javascript settles down somewhat before it gives me hives.