Something that I see discussed quite 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, an 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. This second approach 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.
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. It might also come 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 – no 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 is 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. 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 in contrast 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.”