Supporting previous versions of the software (Part 3)

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)

Supporting previous versions of the software (Part 2)

Well, actually, the topic of this post should be more like, When to drop support for the previous versions of the software. In the previous post (Supporting previous versions of the software - Part 1), we did a top level summary of the problem, and what are some of the approaches one should be following.
In this post, we will talk about the usage of data analytics to determine the number and percentages of users who are using previous versions of the software, and how to use these data analytics to work out whether to continue support or not. Say, if the data is able to determine that there are only 1% of users who are on a version that was released about 5 years back, then it would really help in the decision making. One of course needs to keep in mind that the data cannot be the only factor in determining the dropping of a support, but it is very useful to have such a data rather than trying to make a decision without this kind of data.
How does one get this kind of data ? Well, it is fairly easy to make the application to be phoning back whenever the user launches the application. The data phoning can be incorporated in various different ways - it can be incorporated to repeat the first time that the user launches the application, it can also track how many times each feature was launched in the application, for how much time, what were the workflows involved, and so on. This data coming into the applications data gathering mechanism can be tweaked to do whatever kind of analysis is required.
This data provides a great amount of input into the decision making process. For an application that has around 10,000 active users across versions, if there are only say 100 users working on an application version that was released 5 years back (and during the year of release of this version, there were around 900 users); it is possible to make a decision that support for this software version could be dropped. In many cases, the product team could try to entice these users on previous software versions by offering them a discounted upgrade path to the newest version.
However, using data analytics comes with its own challenges. There are many cases where there are challenges in data collection, or in data analysis. It needs to be very very sure that there are no errors during this process of data collection and analysis. And there are legal issues that need to be settled. This concept of sending data from the application needs to ensure that there is no violation of the privacy of the user (there can be heavy penalties in case it is found that privacy of the user has been violated). Hence, the functionality of this kind of data collection and data analysis would need to be cleared by somebody in the organization who has the authority to clear such kind of privacy potential issues (can be the legal advisor in the company).
Read the next post in this series here.

Supporting previous versions of the software (Part 1)

It is one of the biggest challenges of software development companies. Over a period of time (years), there are different versions of the product that get released. The discussion that happens gets interesting when the company has to decide which previous version of the product needs to remain supported. It is not an easy decision for the company to decide whether to drop support for previous versions of the product; after all, when the company does decide to stop support for a previous version of the software product, there may be a number of users of that software who raise objections. I have worked with a team which had to make that decision on an ongoing basis. The team would release a software every 15 months which had tens of thousands of paying users, and it had been ongoing for more than a decade. As a result, software was being supported that was released more than a decade back. A long time back, when the company had decided that software support would be stopped when the product was released more than 5 years ago, there was a firestorm released onto the support forums and other networks, and had the potential to be damaging PR. As a result, the company decided to reverse the process of dropping support without getting much more data. During the analysis of this decision and the reversal, it was clear that the data for this decision was not really analysed to the level it was expected to be. It was decided that the next time that this decision of dropping support was to be taken, it would need to be done only when there was adequate data for the same; or at least much more analysis of the decision.
What needed to be done ? Well, the basic data for taking such an decision would be to determine how many users of that particular product version were still there, and what percentage of the total users were still there on that particular version. It would be easier if the instrumentation for this was built into the various products; in which case, it is a matter of building the analysis that takes the data from the different software product versions out there in the market and determines the percentage of users who are still using the different software versions out there. What we finally decided was that once the percentage of users of a previous software version dropped to below 4% and it was the software version that was released the earliest, we would start notifying users, going to support forums and the various social networks to explain the reason for dropping support, providing the users with an upgrade path and the proper explanation for the reason for dropping support.
When this decision is communicated many weeks or months in advance of the timeline, it helps the users to come out in favor or against the decision and lets the team react to these and provide the explanation for the same. Once this kind of discussion happens, it lets many users understand the basis for the decision and maybe even accept it (a lot of users just want to understand why something like this has taken place).

Dropping support for a software version is complicated, we will need more posts to walk through the reasoning and the reasons for the same. Look forward to the next post in this series (Part 2)