Your browser is unable to display this site correctly. Please try an up-to-date version of Chrome or Firefox instead.

< Back to all posts

The Dilemma of Software Updates

Emmanuel Ballerini

By Emmanuel Ballerini

Senior Technical Developer (Alumnum)

May 20, 2010

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.

About Jonah Group

Jonah Group is a digital consultancy the designs and builds high-performance software applications for the enterprise. Our industry is constantly changing, so we help our clients keep pace by making them aware of the possibilities of digital technology as it relates to their business.

  • 24,465
    sq. ft office in downtown Toronto
  • 156
    team members in our close-knit group
  • 21
    years in business, and counting