Often teams discuss if their product should upgrade to the current version of used components, development tools and programming languages.
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 product will become a geriatric solution.
Below I show you 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 must include security patches in your product in a timely manner. Other approaches are deeply unprofessional and unethical.
You should use actual Java JDK and JVM version because the community is concentrating their effort on the latest version. And 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 end of September 2018, older versions are no more publicly maintained -.
If for some reasons you are using an older commercially but no more publicly supported JDK, you must sign a support contract with 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.
You should use actual Java JDK and JVM version because the community is concentrating their effort on the latest version. And 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 end of September 2018, older versions are no more publicly maintained -.
If for some reasons you are using an older commercially but no more publicly supported JDK, you must sign a support contract with 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.
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 eliminating incompatibilities and subtle errors from use cases. Having older versions will hinder you to support actual timezone changes or extensions in the Unicode standard.
Actual versions of standards - Unicode, HTTP protocol, time zones - help eliminating 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 Backports
Writing code for older versions of libraries, frameworks, or runtimes means backporting to older API 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 you always free such resources in your application.
The literature states this is neither easy nor error free. It is the root reason why such a feature was added to Java.
Often teams forget the consequence 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.
The literature states this is neither easy nor error free. It is the root reason why such a feature was added to Java.
Often teams forget the consequence 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 no using such constructs disqualifies you as a professional engineer.
We observed how whole teams became demotivated because a huge part of their daily work was backporting to old environments.
We observed how whole teams became 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.
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.
No comments:
Post a Comment