You need to be Agile
I updated my apps on my iPhone today. I tend to do that most days as I don’t want to get too far behind. I do this because I know that the software companies are continually fixing bugs and adding new capabilities to their applications. Once in a while, I may get a version that introduces a bug due to insufficient regression testing, but 99.9% of the time the updates are accretive. The bigger challenge is learning how to use new and improved functionality. This is especially the case when there is an update to the mobile operating system.
I strive to ensure that I have a back up of the phone at all times in case something truly bad happens where a specific function that I count on is not working at all. I know I can restore from that backup. However, I can’t remember the last time I used that function because I know if a bug is introduced, it will quickly get fixed. Software companies cannot afford negative social media and they are quick to ensure they close down any bugs quickly, but even more than that, they work hard to ensure they don’t introduce them in the first place.
I have been working professionally in and with Information Technology since 1989. Windows 3 had just been introduced and there were bugs. There were always bugs. Windows was just another DOS program that if you did the wrong thing would provide you with a blue screen and a loss of a significant amount of work. This was well after the mainframe community and industry had recognized that using the waterfall project management methodology, it would be a long time till another update came out that would fix bugs in the applications. It was critical that software companies maintained and published the intrepid supported/retired version listings that companies depended on. The cost to organizations of being on a failed unsupported version had proved to be astronomical. The industry operated in this way for 30 years, with corporations having a careful policy and legal language that indicated what it would and wouldn’t accept from the software vendor. Both sides needed their own level of protection.
Large organizations move slowly and legal precedents even slower. But around 2005, something began to change. A younger and more capable generation came along and took a technical and management pivot and said, “look, we can shorten the release window, deliver more functionality sooner, and release more often if we change our approach”. Agile was born. This was looked on with reproach by the larger organizations, but as people caught the vision and we all somehow embraced the concept with our handheld computers (smartphones) the world has shifted.
All organizations have accepted Agile in some way. There are two strong examples of this. Microsoft office has become something we subscribe to and automatically accept updates for. There are many reasons for this, not the least is that this is generally the only way to fix security issues that can make an organization vulnerable to hacking (cataclysmic risk). Organizations also allow the Chrome browser and java. The best bet is always to accept the patch.
Added to this is the prevalence of SAAS (Software as a Service). Apps have moved online. These are constantly being patched to fix bugs and release new functionality. No one is asking that an earlier version be supported. That question does not even make sense.
The last stronghold of the Major, Minor version is the smaller software vendor that provides software to larger companies that can be installed and used on-premise. If the software company is older, they will likely have some kind of a major, minor version strategy. But the younger organizations know they need to release small and stay with the velocity of the industry which everyone knows changes very quickly. They can release as often as weekly and of course, must quickly close bugs within a day if they have been introduced.
Large organizations need to allow this to happen and exercise best practices of backups and internal validations as they accept quick changes to support increased security and enhancements. The legal language requiring the support of the current major version and one prior version is no longer relevant. New language to protect both parties needs to be invoked so that corporate software assets can approach the value and convenience that we now demand for our personal phones.