In the previous post (Supporting previous version of the software - Part 2), we talked about having analytics and data information about the number and percentage of users who are using the version of software that is proposed to be dropped, and hence the organization can take an informed solution.
In this post, we will talk about a situation where the hand of the organization is forced. For those involved with designing software products, the question of component dependency is a double-edged sword. When you are making your own software (we'll consider the case of building a software product for the Windows environment), you do not build each and every functionality. There are many organizations that have built components that do specialist work much better than you would be able to do so. For example, for building a video application, it would make more sense to license the usage of a specialist video codec that does it much better than you could. With this advantage, there are some disadvantages as well. You have locked yourself to this component (and large modern software products may use tens or hundreds of such components). In most cases, even when the external component gets upgraded, the upgrade would happen in such a way that software products using such a component can still work. However, over a period of time, especially when a number of years have passed, there can be many problems that come up because of this component dependency. For example, the company that has built the component has gone out of business, or sold the business, or did something similar. This may still work, but it gets even more complicated when defects start cropping up in that component (and customers start reporting those defects). In such cases, when the version of the software is pretty old (more than a couple of versions old), the organization starts veering to the decision that it cannot fix the problem. Even if a fix of the component gets available in some way, it would just be possible to easily fix the problem, or the effort involved to fix, and test this problem would be deemed as not justified.
Consider another case where the software dependency is on some component for which support itself has been withdrawn. Consider the case where you would have integrated a previous version of the Internet Explorer browser support in your product, and Microsoft has withdrawn support for this version of the Internet Explorer. When you start running into multiple such problems, then taking a decision to drop support becomes easier.
Read the next post in this series (Part 4)