This is a line of posts that talk about the reason why software companies may drop support for a previous version of software that they have released. For example, Microsoft has released many previous version of the Operating Systems (out of which a number of them are no longer supported), many previous versions of its Internet Explore Browser (again, many previous versions of the browsers are no longer supported), Adobe has released many previous versions of popular software such as Photoshop or Acrobat (and periodically drops support of previous versions of the software), and so on. Does it mean that there are no problems when the organization drop support of these versions of the software ? No, but the number of users who are outraged by this dropping of support is low or there is an upgrade path for those users and hence it is possible for the company to do this.
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)
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)
No comments:
Post a Comment