We’ve been thinking lately about the pros and cons of updating some older B2B client sites that have been chugging away successfully for years.

“If it ain’t broke, don’t fix it”

Although there is obviously something to be said for that old adage, it doesn’t apply well to web software. On the surface, there may be little motivation to invest in updating old software as long as it’s still getting the job done. The current system has been battle tested, users are familiar with it, and most of the worst kinks have been found and fixed.

But there are real costs and risks associated with failing to update old software. Some are visible, some are hidden.

Visible Costs and Risks:

• usability: older web software typically doesn’t adequately leverage client-side technologies that increase usability and user efficiency. Most older interface designs would benefit from various techniques and technologies, including:
  • increased use of client side interaction via javascript and AJAX to allow for relevant dynamic information to be displayed in the context of the user’s workflow, with fewer clicks between related pages and fewer complete page redraws.
  • consistent approaches to layout and interface features, aided by tools such as standard javascript UI libraries and Bootstrap, reduce user learning curve and increase cross-browser compatibility.
  • better adherence to REST principles to allow for better addressability of specific resources, easier collaboration between co-workers (for example, emailing links to specific warranty claim details), more reliable use of browser history, bookmarks, and the “back” button.
  • layout optimized for higher resolution displays, preferably utilizing a “responsive” design that is optimized for today’s typical sized monitors while adjusting gracefully to smaller devices such as netbooks, mobile phones, and tablets.
• brand image: it’s usually obvious to users when a website or application interface looks “old”. Depending on the nature of your relationship to your users, this may send a bad message that you don’t care about the users’ needs, don’t care about the process the software supports, aren’t up on technology, etc.
• performance: old web software often has relatively poor response time. Users today usually have fast Internet connections, and have higher expectations on web response time than in the past. A latency of 2 seconds at the server wasn’t much when it took 7 seconds to transfer the content, but as the content transfer becomes closer to instantaneous, the server response time becomes more of a noticeable bottleneck. For this reason, new development projects use modern web frameworks with performance features like memory-resident application code, template caching, and shared persistant database connection pools to greatly improve the time needed to service requests on the server side.

Hidden Costs and Risks:

• testability: the industry has made great improvements in the software development process since the early days of web apps. New web apps are typically developed using an MVC (or similar) design pattern, with object oriented design and a solid suite of automated “unit tests” for the data model. Older software which was developed with a more procedural approach and mixed control logic and data access is inherently more difficult to test, and as a result old code is dramatically more prone to develop hidden “regression” bugs resulting from minor changes to application code or operating environment.
• support skill set: as developers move on to newer (and better) development methodologies, patterns, and habits, the tech team’s facility with the older style code tends to fade over time. Add to this a certain amount of turnover in a software organization, and it’s not too surprising that older code starts to look very unfamiliar to the current support team.
• platform dependencies: most software has numerous obvious or hidden dependencies on third-party application libraries, operating systems, and server software (e.g. database or http servers). Over time the versions of these dependencies originally used during development and deployment inevitably become obsolete and unsupported. This problem eventually becomes evident when trying to move the older code to a newer production platform, and the application code doesn’t work correctly with the new version of the dependencies (and the old versions are either no longer available or have serious security flaws).

It’s often tempting to downplay the hidden risks. However, investments in testability and maintainability can reduce the risk of major problems down the road.

A Word About Browser Support

It should be noted that updating client-side code to better service users with relatively current browsers will cause new compatibility problems for any users with very old browsers. Therefore, prior to any modernization project a baseline for browser support should be established on 2 levels:

• the minimum browser versions required to be able to use all site features
• the level of support offered to users with browsers older than that

Browser support isn’t as big an issue as it used to be, for several reasons:

• the big web players (google, facebook, etc.) require relatively recent browsers and this motivates users to upgrade
• Microsoft has been aggressively upgrading IE versions via the windows update mechanism, because they don’t like supporting older browsers (for security and other reasons)
• popular client side libraries (Bootstrap, jQuery, etc.) do a pretty good job of “papering over” browser incompatibilities so the developer doesn’t need to worry about them

A reasonable strategy is to officially support only those browsers supported in the current stable release of Boostrap (currently IE7+, Firefox 5+, Safari 5+, Chrome 14+). IE7 has been out for 7 years now, and older versions of IE are very problematic from both capability and security perspectives. As a point of reference, Facebook requires IE8+ and Google supports only IE9+ (and equivalent generations of Firefox, etc.)

As of this writing, conventional wisdom is that users should be expected to have javascript and cookies enabled, but should not be expected to have extra client-side technologies such as ActiveX, Java, Flash or Silverlight.