Six reasons staying upgraded

In my opinion when it comes to software development in medium to large size organisations there are often several types of restrictions and obstacles continuously upgrading the underlying frameworks and dependencies used in the platform. Motivations like cost (we’ll come back to that one), trust or unrevealed bugs (not yet discovered by others) are not uncommon, it could also be as simple as laziness by others in the organization not being directly affected by the legacy dependencies.

At PriceRunner we aim to use the latest available versions for our dependencies and third party platforms, of course we as a tech department need to balance the continuous upgrades with feature development as in any other organisation but we have an clearly stated ambition to always have a modern platform which is recognized also by the top management.

But why are we doing this? Our six top reasons are:

Security
As with any other software — security issues are reported and fixed every day, we have all learnt to update the software on our computers and smart phones to avoid being exposed to security threats. The same goes for our dependencies although it might not be as easy to identify which are the most critical ones.

Performance
Some time ago we upgraded our underlying platform XAP (GigaSpaces) from version 12.3 (using jdk8) to 14.5 (using jdk11), of course we wanted to benchmark the two versions and below you can seen the difference in response times. This is only one example where we (as platform users) gain a lot in terms of performance just by upgrading version.

DX - Developer Experience
Most tech firms today invests heavily in competence development usually by allowing their employees attend to different conferences around the world. Although this is a nice employee benefit it should also give some value back to the company. However if you as a software developer never get to use the new features that you got inspired by in the conference because of the legacy platform you are using in your daily work - the intended value will fade away fast. In the long run the motivation to attend these conferences will decrease and even worse employees might look for other opportunities.

Developer speed
As languages evolve solutions gets easier to write, the functional way of expressing solutions in jdk8+ is a great example where functions can decrease ten fold in number of lines of code. This of course has an
effect on the development speed and hence the short-term investment (upgrading to a new version) offer the company return.

Several small steps instead of a big leap
In almost every case it´s easier to continuously make smaller updates than jumping large version gaps. Given that you have a light weighted release process and sufficient test coverage - updates will not consume an extensive amount of time. If issues related to the upgrade are discovered it’s most probably easy to pin point the specific issue and if needed rollback.

Contributing to the open source community
Regardless of your company open source contribution policy you can always contribute by using the latest versions (or maybe even the release candidates) in your production environment. If you encounter a bug, report it and you have most probably saved someone else from hitting the same issue.

A real life example
Here is a short description of an issue we ran into when migrating to the new http client released in jdk11. Suddenly a integration test started failing with the following stack trace;

java.lang.IllegalArgumentException: restricted header name: “Content-Length”
 at java.net.http/jdk.internal.net.http.common.Utils.newIAE
 at java.net.http/jdk.internal.net.http ...

The same application worked just fine using the RestTemplate class in Spring (which in turn relies on the Apache http client) but apparently not with the http client shipped with OpenJDK.

Once again someone else faced the same issue (before we did) and filed a report (https://bugs.openjdk.java.net/browse/JDK-8213696) and already in the next release (jdk12) there was a system property available to overcome this problem:

jdk.httpclient.allowRestrictedHeaders=Content-Length

If your company has not already embraced a continuous upgrade strategy here are a few tips that might help

• Ensure that applications can be easily upgraded independently - we write micro services running in Docker containers and upgrading Java version for a service is usually as simple as replacing the Docker image tag and release number in the configuration for the Maven compiler plugin.
• Enforce sufficient test coverage. In well tested projects breaking changes in dependency upgrades are immediately caught by the tests.
• Make sure that the results (usually performance metrics is the easiest one to get hard numbers from) are presented to the business stakeholders. This way prioritizing future upgrades gets a whole lot easier.
• Spread the word - usually some team members are more enthusiastic than others when new versions are released. But once your team has upgraded make sure to spread the word and other teams will follow.
• Read the release notes or change log, as well new features as limitations are often documented.