Why Use Current Software Components?

2017 12 02 head

Often, teams discuss if their digital product should upgrade to the current version of open-source or commercial used components.

The same discussion arises for development tools and programming language versions.

I have a strong opinion about upgrades. You should always use the current version of all components included in your product. The only discussion is the timely when and never the if.

Be realist, if your product is successful, you have to upgrade before the components are obsolete. Otherwise, your application will become a geriatric solution.

Organizations often forget the liability of using older versions of components with known and published security flaws [1].

Below, I provide you with arguments why you should always update all components in a timely fashion.

Security and Governance

Social responsibility and liability considerations require your product to be immune to published attacks. Your company shall provide reasonable protection to all your customers. Therefore, you always include security patches in your product in a timely manner. Other approaches are deeply unprofessional and unethical. In some countries, you are liable if you do not update your software to avoid known security attacks.

You should use actual Java JDK and JVM version because the community is concentrating their effort on the latest version. Oracle only provides public support for the latest two Java versions, e.g., in January 2018, Java 9 and Java 8 are officially supported. Java 8 support will stop at the end of September 2018, older versions are no more publicly maintained.

If, for some reason, you are using an older commercially but no more publicly supported JDK, you must sign a support contract with the Oracle company and pay for it. You cannot use deprecated JDK versions because nobody provides security fixes on these versions, e.g. Java 6 commercial support ended in December 2017.

If you include a deprecated JDK / JVM in your product, you willingly endanger your users and shall be liable for their losses.

Governments started to realize how unprofessional organizations are working. Recommendations and laws are grafted to force better security [2].

Upgrades and Genuine Improvements

The component developers put tremendous effort to improve the non-functional aspects of their products. Performance and scalability improvements between Java versions are impressive. You shall not hinder your own customers to rip these low-hanging fruits.

Actual versions of standards - Unicode, HTTP protocol, time zones - help eliminate incompatibilities and subtle errors from use cases. Having older versions will hinder you to support actual timezone changes or extensions in the Unicode standard.

Training and Community Support

Good training and associated certification are only available for actual versions of languages, frameworks or library. You will not find any training for Ada, Apache server 1.x, or any object-oriented database.

The articles in Stack Overflow and the community always cover the current version of components. So you are on your own for support or code examples for older versions of libraries.

Hidden Cost of Backport

Writing code for older versions of libraries, frameworks or runtimes means backporting to older application interfaces and features. For example, if you do not have access to auto-closable resources, you have to write your own framework and software checks guarantying closing system resources. You should always free system resources in your application. The literature states this is neither straightforward nor error free. It is the root reason why such a feature was added to Java.

Teams often forget the consequences of back porting. Later, when you adopt a more modern version of your dependencies, you have to remove all this now spurious code and migrate to the build-in concept. Otherwise, the code is no more maintainable and changes are error-prone.

In other words, you have to twice work when backporting, once to build it in, and a second time to later remove it. This solution is certainly not the most economical one.

Motivation of Team

No professional developer wants to write source code using JDK 7 or older versions. They want to develop using modern and powerful constructs such as lambda, modules, HTTP/2. I would state that not using such constructs disqualifies you as a professional engineer.

We observed how whole teams become demotivated because a huge part of their daily work was backporting to old environments.

I understand that geriatric software solutions do not allow you to use the latest versions. It is time to bury such products and to go on. The only open question is the date of the burial. Do not wait too long, decomposition is never nice to smell.

Maintaining or extending software based on old versions of libraries is just throwing money out the window. You need a solid basement to build on.

1. Data privacy and protection laws were established in Europe in 2018 and in Switzerland in 2020. Companies and executives can be sued, sentenced to pay huge fines, and in the worst case, C-level managers get a criminal record entry. Such an entry can destroy your career potential. For example, you are banned from becoming a board of directors members of a lot of companies.
2. The White House in the USA initiated an Executive Order on Improving the Nation’s Cyber-security in 2021. The goal seems to be the definition of minimal rules for software products to minimize known security risks.