Something that I see discussed very often in IT circles is “which version of software should I install.” This could apply to a database, an application, firmware or, probably most often, operating systems, and with the upcoming end of support life for Windows XP the topic has reached a fevered pitch.

There are effectively two sides to this discussion. One side believes that the latest and, presumably, greatest software should always be used. The other believes that software needs to mature and take a “wait and see” approach or even considers each version to be a different product and not a continuum of development.

Both approaches have their merits and neither should exist completely without the other. Blindly updating software willy nilly is not wise and avoiding patches and updates without reason is not wise either. Careful consideration of the factors and empathy for the software development process are important to keep in mind when making these decisions.

First, there are two completely different scenarios to consider. One is the updating of current, existing software. The assumption being that the current state of things is “working” with the accepted possibility that “working” might include a security exposure that has been discovered and requires updating in order to close. The other scenario is a new deployment where there is nothing currently and, we are starting from scratch.

Let’s start with the second case, as it is far easier to provide guidance on.

In the case of new software deployments (or new operating systems), always use the current, most recent version of the software unless there is a clearly known technology limitation preventing it ?? such as known bugs or software incompatibilities.

Software is not like other types of products, especially not in today’s world of online patch releases and updates. I assume that the mentality that old versions of software might be preferable to current ones comes from a combination of physical products (watches, cars, dishes, furniture, wine) where a specific year or model might be superior to a newer model for various reasons and from legacy software delivery modes where finished software products were just ??thrown over the wall? and the final state was, quite simply, the final state without any reasonable opportunities for updates, patches or fixes. Neither of these cases applies to modern business software (with only the rarest of exceptions.)

Software development is roughly a continuum. Normal development processes have new software being built on top of old software either directly (by creating updates to an existing code base) or indirectly (by rebuilding based on knowledge gained from having built a previous version of the software.) The idea being that each subsequent version of software is superior to the one preceding it. This is not guaranteed, of course, there are such concepts as regression errors and just bad development, but by and large, software improves over time – especially when we are talking about enterprise class software used in businesses and under active development. New software is not just the next phase of the old software, it also represents, in nearly all cases, the current state of patches, bug fixes, updates and, when necessary, changes in approach or technique. New software, coming from quality shops, is almost exclusively better than old software. Software evolves and matures.

Beyond the quality of software itself, there is the concept of investing in the future. Software is not something that can sit on the shelf forever. It needs to stay, to some degree, up to date or it stops functioning because the platform that it runs on changes, some new artifact comes to light, security holes are discovered or needs change. Installing old software means that there is an investment in the past, an investment in installing, learning, using and supporting old technology. This is called “technical debt.” This old technology might last for years or even decades, but old software loses value over time and becomes increasingly expensive to support both for the vendors, if they continue to support it, and for the end users, who have to support it.

The same concept of technical debt applies to the software vendors in question. There is a very large cost in creating software and especially in maintaining multiple versions of that software. Software vendors have a lot of incentive to reduce support for older versions to focus resources on current software releases (this is a major reason why SaaS deployments are so popular, the vendor controls the available versions and can eliminate legacy versions through updates.) If customers require support for old versions, the cost must be absorbed somewhere and often it is absorbed both in monetary impact to all customers as well as a decrease in focus on the new product as development teams must be split to support patching old versions as well as developing the new. The more effort that must go in to old versions, the less effort that can be put into new improvements.

Within the framework of what I have already said, it is important to talk about code maturity. Often code maturity is stated as a reason for deploying “old code”, but I think that this is an IT misunderstanding of software development processes. If we think about a released line of code, just because it is released and in use does not really make it more mature. Code does not change in the wild, it just sits there. Its maturity is “locked” on the day that it is released. If it is patched, then yes, it would “mature” post release. Later versions of the same software, based on the same code base but more up to date, is truly the more “mature” code as it has been reviewed, updated, tested, etc. to a greater degree than the early release of the same code.

This is counterintuitive to, say, a car where each release is a fresh thing with new opportunities for mechanical problems and different reliability concerns – where waiting a few years gives you a chance to see what reliability issues get uncovered. Software is not like this. So the concept of wanting more mature software would push you to deploy the “latest and greatest” rather than the “tried and true.”

If we think of software version numbers rather like ages, this comes through.  Linux 3.1 is much older, in terms of software maturing, than Linux 2.4.  It has a decade of additional development.

Let’s use a real world example that is very relevant today. You are in a shop about to install your first server(s). Windows Server 2012 R2 has just released. Should you install Windows Server 2008, 2008 R2 (2010), Server 2012 or Server 2012 R2 (late 2013?)

To many shops, this sounds like we are talking about somewhere between two and four different products entirely which probably have different reasons for choosing each. This, by and large, is untrue. Each newer version is simply an upgrade, update, patch and feature increase on the previous one. Each one, in turn, is more advanced and mature than the one preceding it. Each new version benefits from the work done on the original release of its predecessor as well as bug fixes, patches and feature additions done in the interim between the original release and the successor release. Each new release is, in reality, a “minor release” of the one before it. If we look at the kernel revision numbers, instead of the marketing names of the releases, it might make more sense.

Windows Server 2008 was Windows NT 6.0. Windows Server 2008 R2 was Windows NT 6.1, obviously a minor revision or even a “patch” of the previous release. Windows Server 2012 was Windows NT 6.2 and our current Windows Server 2012 R2 is Windows NT 6.3. If we were to use the revision numbers instead of the marketing names, it sounds almost crazy to intentionally install an old, less mature, less updated and less patched version. We want the latest updates, the latest bug fixes and the latest security issues to have been addressed.

For new software deployments, the newer the software installed, the better opportunity to leverage the latest features and the most time before inevitable obsolescence takes its toll. All software ages so installing newer software gives the best chance that that software will last for the longest time. It provides the best flexibility for the unknown future.

Following this line of thinking might lead us to feel that deploying pre-release or even beta software would make sense as well. And while there might be specific cases where this does make sense, such as in “test groups” to check out software before releasing it to the company at large, in general it does not. The nature of pre-release software is that it is not supported and may contain code which never will be supported. Using such code in isolation can be beneficial, but for general use it is not advised.  There are important processes that are followed between preview or beta releases and final releases of code no matter what maturity level the overall product is at.

That brings us to the other situation, the one in which we are updating existing software. This, of course, is a completely different scenario to a fresh install and there are many, many more factors involved.

One of the biggest factors for most situations is that of licensing. Updating software regularly may incur licensing fees that need to be factored in to the benefits and cost equation. Some products, like most open source software, do not have this cost and can be updated as soon as new versions are available.

The other really large factor in updating software is a human effort cost to updating – unlike in a fresh installation, where the effort of install is effectively a break even between old software and new.  In reality, new software tends to be easier to install than old software simply due to improvements and advancements.  Maintaining a single version of software for a decade means that resources were not dedicated, during that time, to upgrade processes. Upgrading annually during that time means that resources were used ten times to enact separate upgrades. That makes updating much harder to cost justify. But there is more than just the effort of the update process itself, there is also the continuous training needed for end users who will be forced to experience more changes, more often through constant upgrades.

This might make updating software sound like a negative, but it is not. It is simply an equation where each side needs to be weighed. Regular updates often mean small, incremental changes rather than large leaps allowing end users to adapt more naturally. Regular updates mean that update processes are often easier and more predictable. Regular updates mean that technical debt is always managed and the benefits of the newer versions which may be features, efficiencies or security improvements, are available sooner allowing them to be leveraged for a longer period of time.

Taking what we have learned from the two scenarios above, however, there is another important take away to be found here. Once the decision to perform an update has been made, the question is often “to what version do we update?” In reality, however, every update that is more than a standard patching process is really like a miniature “new software” buying decision and the logic as to why we “always” install the newest available version when doing a fresh install also applies here. So when performing an update, we almost always should be updating as far as we can – hopefully to the current version.

To apply the Microsoft example again, we can take an organization that has Windows XP deployed today. The business decides to invest in an update cycle to a newer version, not just continued patching. There are several versions of the Windows desktop platform that are still under active support from Microsoft. These include Windows Vista, Windows 7, Windows 8 and Windows 8.1. Updating to one of the less current versions results in less time before that version’s end of life which increases organizational risk, using older versions means continued investment in already old technologies which means an increase in technical debt and less access to new features which may prove to be beneficial once available. In this particular example, newer versions are also considered to be more secure and require fewer hardware resources.

Every business needs to find the right balance for them for existing software update cycles. Every business and every software package is different. Enterprise software like Microsoft Windows, Microsoft Office or an Oracle Database follow these models very well. Small software projects and those falling near the bespoke range may have a more dynamic and unpredictable release cycle but generally will still follow most of these rules. Consider applying empathy to the software development process to understand how you and your software vendor can best partner to deliver the greatest value to your organization and combine that with your need to reduce technical debt to leverage your software investment in the best possible way for your organization.

But the rules of thumb are relatively easy:

When deploying new or updating, shoot for the latest reasonable version of software.  Use any deployment opportunity to eliminate technical debt as much as possible.

When software already exists weight factors such as human effort, licensing costs, environmental consistency and compatibility testing against benefits in features, performance and technical debt.