The Dilemma of Software Updates

On every single IT project, softwares, tools and frameworks are chosen to develop the system components. Those tools and applications are selected based on many criteria: relevance to the project, easiness to use, price, license, knowledge from the team and so forth. Versions are chosen based on the same criteria.

Fairly often, a project starts and after a few years, versions have not changed for most tools and frameworks, even though newer versions that offer new features are available on the market. To the question “why have you not changed the versions?”, most managers would answer “why should I since everything is working fine?”. I believe there are four main reasons why upgrades should be applied:

  • as new versions get released, old versions tend not to be supported anymore
  • working with old versions can decrease productivity
  • new version promotes innovation and keeps team members excited
  • new features or patches in up-to-date versions can solve issues with old versions

Here is a specific yet very common situation: a Java project starts and a license for an application server version x is acquired. This application server works with Java version y. After a few years, the vendor that provides the support announces that there is no more support for version x because Java y is now too old. The only way to have support is to update to version x + 1, which requires Java y + 1. Therefore, two technical upgrades are required, either of which might interfere with the timely implementation of new requirements, or indeed the stability of the system as it stands. To me, it seems that often upgrades are made when there is no other option. This could potentially be more expensive than if the upgrade had been planned ahead of time.

As new versions become available, new features arise, some of which are very helpful and have a big impact on productivity. However, an old version of tool A is not always compatible with a new version of framework B, which means that the old version of B cannot yet be retired on the project, although the new version of framework B could help the team in many ways.

I have personally worked with an up-to-date version of my favourite IDE for many years. Because of the client-mandated use of an old version of an application server incompatible with the newer version, I even had to downgrade it to an old version once. Many features of the most recent version were not available on the old one, and I believe my productivity suffered from it.

To be smooth, upgrades cannot be done in a rush and people in charge need to do their due diligence on an ongoing basis. By doing so, they keep themselves aware of what is available, and are in a better position to evaluate the best possible time for an upgrade. The value of bringing innovation to the project could be significant in the case where newer framework versions solve some major issues faced on the project.

The legitimate question is “when to upgrade?” Right when the new version gets released? I would not be that strict because new versions often have defects that usually get fixed in the first few months after their release. An upgrade 6 months or so after the new version release is probably a better option, unless you simply can’t wait to use the new feature set. The specific timing is less important that the up-front planning that allows the updates to be smoothly incorporated into the project plan.

Add a comment

Comment feed
The better to greet you with
No one will ever see this
Your pride and joy
The reason this comment form exists

The crew behind ASOT

We're a team of interactive, software, and business intelligence experts skilled in the design, construction, and management of online enterprise systems.

Visit The Jonah Group site

Get in touch with us