Timing a Software Update, Mid-Project

New software versions can be the Ninja assassins of the software world. Picture your innocent software team, working diligently, creating new features, pleasing product management and customers.

Then, usually at the most inconvenient possible time, a new version of some software you interact with is released. Maybe it’s a new version of Rails, or a new version of the NFS spec or a new version of Java.

Drop everything and upgrade? Not a good idea. For most software of any complexity, you probably want to let it shake out in the field for a bit before you upgrade. And if the software doesn’t have new features, well, then there’s no rush to upgrade.

But wait too long and you have software that is too old to be supported. That leads to bug reports that look like this:

Bug: X doesn’t Y in the frobble. We’re using version Really Old.

Comment: That version is no longer supported. Upgrade.

And now you’ve got a bug — possibly a big bug — and you have to take on the upgrade more urgently than you’d like.

Best Timing for Upgrades

At my client sites, we use the following rules of thumb for upgrading components.

Do not upgrade before:

  • The first patch version has been released. For example, if upgrading to 1.7, wait until 1.7.1 comes out. This means we don’t expose customers to some potentially large bugs, most of which tend to be fixed in the first release.
  • The hosting provider supports that version in production. We don’t want to host on a beta site. Period. Note that for installed software, “hosting” can mean the operating system on which the software runs.
  • The toolchain supports it. That means we don’t upgrade Ruby, for example, until the gems we use support the new version. Sometimes that means we make the toolchain support it (by updating a gem and contributing that back, for example).

Definitely upgrade when:

  • A component is more than one major or two point versions old. When 4.0 comes out, it’s definitely time to get off 2.x, for example. The same goes for dot releases; when 3.5 comes out, it’s time to upgrade off 3.2.
  • You need a new feature. We saw this with Java when it added support for generics, and with Rails when it put in the asset pipeline. That new feature was a strong incentive to upgrade because it made building our product features easier and better.
  • You can no longer get support easily. This doesn’t just include product support from the vendor. When our forum questions don’t get answered because we’re on an old version and no one else is using it, then it’s time to upgrade.

The trick with upgrading is to remain in the part of the software ecosystem that provides your team with the most resources. It makes getting support easier; it gives you  more toolchain choices; and it makes hiring easier. Sometimes it’s hard to schedule an upgrade among the software features and customer questions, but it’s important. So keep upgrading, and keep up.

Image: Bigstock

Comments

  1. Pretty great post. I just stumbled upon your blog and wanted to mention that I have really enjoyed surfing around your blog posts.
    After all I will be subscribing to your rss feed and I’m hoping you write again very soon!

Post a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>