Software Upgrades: A Mixed Bag

Software upgrades often leave computer users disgruntled.  Upgrades are designed to fix bugs and add new features.  However, adding features typically adds complexity, which can obfuscate work that had been comfortable.  A common complaint is that it now takes 5 clicks rather than 2 for an often repeated operation.  A useful feature may have gotten buried in sub-sub-menus.  User interfaces change in ways that some users don’t like or don’t get.  Sometimes features are removed, perhaps because they were deemed of minimal importance, or the development budget didn’t allow them to be ported into the new codebase, or the vendor pulls them out so they can be sold in a separate or more expensive package (which actually happens fairly frequently).

Upgrades can leave users in a quandary in other ways as well.  New bugs may be introduced, possibly hitting some users in exactly the wrong places.  Bloat-ware is another chief complaint.  New versions may be much larger and run slower, bogging down the computer, especially as old codebases are tweaked and appended to rather than being rewritten.  There are times when a new version is less reliable than the old, leading to errors, frustrations, and computer crashes.  Many times new versions only work well if the hardware is upgraded, an added and often unforeseen expense.

Another common lament is that an upgrade or new version has been released prematurely, without having persevered through rigorous quality assurance.  (“Version 1 is really the next beta.”)  This is a disturbing phenomenon that sometimes leaves users wondering what committee is in charge.  A very popular website and portal (one I use frequently) seems to undergo a major facelift every couple of months.  Whenever this happens, very basic (as in front page) features usually get broken.  Within a couple of weeks things are fixed, but very normal regression testing, and even a simple checklist matrix would have flagged those bugs before release.  Many updates smack of pointless churning to most users – despite publicity campaigns to the contrary.

Those in charge of product development sometimes forget a very simple fact.  Unless an update provides a new feature or capability that a particular user wants or likes, the change itself is a negative event for that user.

Thus upgrades may make users feel disabled and abandoned, or cramp their style.  Most serious users of popular desktop operating systems and office products have felt this displeasure at one time or another.  All in all, software upgrades are positive, but there are exceptions.  Many users hold off adopting major releases for at least several months’ worth of patches, and some users have even resorted to paying extra for “downgrades” to get back to a more reliable platform.

Another common snag is that companies buy into an upgrade of a major platform, for its many advantages or because of certain overarching priorities.  However, they sometimes discover that their workhorse software products and systems are no longer compatible.  They may be forced to run multiple platforms just to maintain the old and the new, and they spend a great deal of effort to bridge the different systems.  The pains of transition and the obsolescence of systems on which they have relied can be traumatic.  Workers may feel like they have been wrenched from their familiar environment, possibly forced into precarious job situations given the skill sets they have.

When software is being evaluated, it is important to be careful about the product versions.  Even if a product has a good reputation, one cannot always assume that the later version will be an improvement.  Different vendors have different track records with upgrades, which is at least a starting point for examination.  Sometimes it takes some digging to get useful scuttlebutt.

Associates in companies that do commodity-like installations of a particular package may prove to be a useful resource for both software specialists and managers looking for useful intelligence on software versions.  These companies are typically involved with many deployments, and may know a lot about the features and idiosyncrasies, and the suitability for various projects.

Sometimes ways can be found to integrate and preserve the old software, or to encapsulate it within the new.  Other times it is better to change it out or rebuild it.  These are real world issues, for which there may not be easy answers, but an expert advisor may be able to present alternatives and help prioritize, and in some cases provide a path for incremental transition, preserving budgets and resources in the short and medium term, so change can happen in a measured way.

Copyright © 2011-2012 Patrick D. Russell
This entry was posted in ARCHIVE (Posts prior to 2013), Cautionary Tales, Tech Advisor/Advocate. Bookmark the permalink.

Leave a Reply

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