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.

How to determine the Operating System support for your product - Part 8

In this series of posts, I have been talking about the Operating System support provided in your applications. In the previous post (Operating System support for your software application - Part 7), I talked about support for 32 bit vs. 64 bit and also talked about how support provided by components can be a huge factor in the operating systems that you support. I took the example of a video application which depends on a large number of external components for codecs, encoders and decoders, for writing to DVD and Blu-Ray and for other parts of the application. If some of these components drop support for an operating system and that component is a critical part of the application, then it is time to take the decision to drop an Operating System. I know of a number of software applications that finally dropped support for Windows XP because 1) Microsoft is on its way to dropping support for Windows XP, with this support ending in 2014. 2) A number of external components dropped support for Windows XP and these were critical enough that the management team of the application finally bit the bullet and dropped support for Windows XP as well.
What happens when you cannot afford to drop support for an application such as where components have dropped support, but the customer profile is such that there is still revenue to be had from customers on this operating system ? Well, that is not a very nice place to be, but you still need to take a stand. If the revenue is important, then you will need to support that specific operating system. So what do you do ? There are a number of steps that you can take to ensure that your product remains on that operating system.
1. Well, you will need to make another effort to ensure that the external component retains support for that specific operating system. If the company or group providing the external component is not willing to provide full support, ask whether they are willing to maintain it to the level that was previously supported. If this is another group in the company, then the revenue potential provides some leverage to ensure that escalation can happen and support is maintained, even if it is at a lower level (only critical bug fixes are provided rather than all bug fixes).
2. The most risky approach. You take a chance and go with a component that is not supported by the provider on that specific operating system. The problem in this case would be that if there is some critical problem that has emerged, things can go out of control very easily, and lead to a situation where there are no good options.
3. Look for alternatives. There are very few functionality items that would not have multiple providers, even if the alternative is a less than perfect functionality. If using another component provides a solution, then you should evaluate the other component and use it if it meets your purpose (even if less than perfect).
4. Prepare for a reduced functionality. I have seen many products using such an approach. When there are no alternatives, and it is decided that support for the specific operating system needs to be continued, then it may be something as easy as dropping the component which has dropped support for the operating system, and having the product without the functionality provided by that component. This needs to communicated to customers as well so that they know that there will be reduced functionality on that specific operating system.

How to determine the Operating System support for your product - Part 7

In the previous post in this series (Operating System support for your software application - Part 6), I focused on the different roles and responsibility of stakeholders in the team, primarily the Product Management, the QE, and the developers. The Product Manager has to take the decision taking into account the various pros and cons of such a move, and also while evaluating revenue impact; the QE and development team would do their contribution to this discussion keeping in mind the impact on their effort, and any technical factors that could also influence the decision. In this post, I will talk more about the dependency and also briefly touch on the 32 bit or 64 bit discussion.
For some years now, there has been an ongoing discussion about the need to move applications onto a 64 bit architecture and stop support for 64 bit architecture. Most people will not understand this discussion, and the reason why it is a top item of discussion for many teams. In near layman's terms, when you state that your application is now 64 bit, it would mean that it can take inherent advantage of the benefits posed by the new wave of 64 bit operating systems, being able to allocate more memory, and numerous other technical advantages. Also, most Operating Systems that are now available are 64 bit. So why not go ahead and convert your application to 64 bit ? Well, converting your codebase to offer native 64 bit support is a project by itself, requiring a large amount of development and testing time. For teams that have limited resources, making such choices is not easy (and most teams cannot claim to have unlimited resources). In addition, you also need to realize that you would no longer be properly supporting consumers who still have 32 bit operating systems (and where the hardware has been supporting 64 bit for a long time now), so this is a decision that needs to be taken.
The other aspect of this post is in terms of the various components that your application would use. In today's world of software development, it is hard to think of a large software that the development team has totally written. Consider that your product is a large video manipulation application. Even though a lot of the workflows will be written by your team, the functionality of a number of sub-areas are better handled by using external components (which could be built by other teams within the company, or by other companies which specialize in such areas). For example, if you are looking at an application that allows users to organize, edit and manipulate videos, you would need support for the different video formats, you would need access to different encoders and decoders, you would need components for creating DVD's or Blue Ray discs as part of the end process. In all such cases, it is far more efficient and effective to use specialized software rather than trying to replicate all of them.
And this is where you dependency starts to dictate matters for you in terms of the operating system support. The external components that you use are created by companies that in turn have to take the same decision for operating system support as you do, and they would also have a large number of customers, based on whom they need to take decisions. It is entirely possible that you would end up in a scenario where some key component that you are using is dropping support for an operating system, and given its criticality in your own application, you are forced to also stop support for the same operating system.

How to determine the Operating System support for your product - Part 6

This blog has seen a series of posts on deciding the Operating System supported by your application. The previous post (Operating Systems supported by your application - Part 5) talked about the kind of constrains that there are for an operating system that is not supported - whether these prevent the user from installing the application on that operating system, or just give a warning and let the user install on the specific operating system. This post will talk in more detail about the process for the various stakeholders in the team that come to a decision about the operating systems to support.
The most important stakeholder is the Product Manager. It is the product manager who is responsible for the final state of the product, the system requirements for the product (which includes the operating systems to be supported in the application). The Product Manager is also the one who is responsible for the revenue requirements for the product, and supporting or dropping an operating system can make a difference to the revenue generated by a product by a few percentage (and these few percentage can make a huge difference in terms of whether targets are met or missed). Hence, it is for the Product Manager to take a final call on whether the product should drop a specific Operating System or not. However, it is perfectly fine for team members to be able to provide a lot of updates and constraints to the product manager.
Another important stakeholder is the QE team (the testers). During the testing phase, the team needs to draw up a plan of which are all the operating systems that need to be supported, need to decide the amount of effort to be spent in each operating system, and then actually put in the effort. Suppose a team supports Windows XP, Windows Vista, Windows 7 and Windows 8. In such a case, the team would use data about the approximate number of users on each operating system in order to prioritize the testing effort on each operating system (no testing team has enough resourcing to do all the tests and spend the effort that they would like to do). But you would still expect that if there are 4 operating systems, then the team would spend around atleast 15% on each operating system testing. In some cases, the testing for an operating system might take more time because there are more defects to be found on such an operating system (for example, we found a lot more problems on Vista, many of them related to the security issues because of the user security accesses control introduced in Vista).
So, the testing team would want that if there is a possibility of reducing an operating system because of a lesser number of users on such a system, then they would hold a number of discussions with the Product Manager on this topic, to ensure that their voice is heard and if they have any data, that is also passed onto the Product Manager (such data could be the increasing number of bugs that they are finding on older operating systems).
The development team are also important stakeholders. They are responsible for ensuring that the code is there for functionality to work the same on all the supported operating systems, something that can be problematic sometimes because the operating systems behave differently. In addition, there may be components in use that are not supported as well on older operating systems.
All these are stakeholders and opinions that need to be factored in before taking a decision on whether to drop a specific operating system. The decision needs to be taken after factoring in a lot of points.

In the next post, I will add more points on this particular topic (Operating Systems support for your application - Part 7)

How to determine the Operating System support for your product - Part 5

This particular series of posts talks about how to determine the support for previous Operating Systems provided in your application (Operating System Support in your application - Part 4). In the previous post, I talked about one major factor - when the maker of the Operating System (whether that be Microsoft or Apple) decides to drop support for the Operating System and will not provide any more bug fixes or other support. This gives a problem where even if you decide to support such an application, you will not get any bug fixes from the makers of the Operating System, which can be a huge potential problem given the interactions of the application with the Operating System.

In this post, I will talk about the process of cutting off support for an Operating System. There are 2 different methods which I have seen about how to cut off support for an Operating System. One of the ways is to provide a hard constraint, which means that the user will not be able to install on that specific Operating System, and the other is a soft constraint which means that the user is given a warning when trying to install on that version of the Operating System.

Consider the variation about using a hard constraint that prevents the user from installing on such an Operating System. What this means is that when the user tries to load the application on that specific version of the Operating System, the application determines the specific Operating System loaded on the computer, and then checks with the supported list of Operating Systems. If the Operating System is not to be supported, then the application installer will give an error to the user and prevent any installation on the user machine. 

Putting a hard constraint is needed when the makers of the software have made a determination that the user should be prevented on that Operating System. This can be when there is a high deal of uncertainty about whether the application will work well on that Operating System without any defects, or when the makers have decided that the version of the Operating System is not in wide user anymore. The hard constraints are also used when the Operating System installed on the user machines is controlled, such as in the case of higher end or specialized software.

The soft constraint means that the user will get a message during the installation process about the version of the Operating System not being supported, and will get an option about whether to proceed or not. If the user decides to go ahead, then the application will get installed. This is normally done when there is an expectation of very few problems on that specific Operating System, and the company does not really want to force the users of that specific Operating System to try alternative solutions. There will be need to be some testing of that specific Operating System, but not at the same level as that of the supported Operating Systems.

Read more in the next post (Determine Operating System support for your application - Part 6)

How to determine the Operating System support for your product - Part 4

In the previous post of this series (Determining Operating System Support for your application - Part 3), I wrote about the process of determining the number of people in your customer base who are using the Operating System in question. There are ways to do surveys and look at industry data, but there is some amount of variability involved even when analysing the data and some amount of assumptions need to be made. Of course, trying to make such decisions without trying your best case on how to get the data required for such analysis is something that organizations should avoid at all costs. Such decisions could cost money that the organization could ill afford, and hence such decision making should be done with a lot of deliberation.
In this post, let us consider another factor that is of great importance in deciding when to drop support for an Operating System from your application. This is related to the drop in support for a particular Operating System by the makers of the operating system. So, if you could consider the case of an operating system such as Windows NT or Win 2000, the support for all of these have been dropped by Microsoft, and if you were to try to get resolution for a problem on these operating systems with Microsoft, they would decline to provide you any support and ask you to upgrade to the newest operating system.
Now you are developing an application that will run on the operating system. Any application, especially those that accesses files on the local machines or that accesses devices on the local machines such as printers (and most applications give a print interface) have a dependency on the files of the Operating System. From time to time, there are problems that crop up where you need to work with the makers of the Operating System (typically Microsoft or Apple) and even expect them to make some fixes for you. When the makers of the Operating System withdraw support, they stop supporting such problems and no longer want to provide fixes for such problems.
So what do you do ? You could still provide support for the Operating System even when the maker of the Operating System is no longer providing any support, but there is an inherent risk in this decision. During the development process, you could run into a problem that could cripple your system and yet you don't have a solution, or a solution on your end is expensive and time consuming  In such cases, it will cause you significant problems; on the other hand, small problems that really are not problems could be all that are caused. And you have to consider that the maker of the operating system would also have thought a lot about dropping support, and there would have been some factors that went into such a decision.
Apple makes it even easier. As and when Apple releases new operating systems, new machines that are released are packaged with these new systems, and they even stop supporting older operating systems on these machines. Deciding on dropping older versions of the Mac is easier than that of Windows, also because the customer base using the Mac Operating System would be less than that of Windows.

Read the next post in this series (Operating System support for your application - Part 5)

How to determine the Operating System support for your product - Part 3

In the past post in this series related to how to determine the Operating Systems support for your application (Operating System Support - Part 2), I talked about trying to determine what your current users support. If your current users are using an Operating System in fairly significant numbers, then it would be hard for you to drop support for such an Operating System; you would risk turning off these users, preventing them from buying the newer version of your software, and drop a significant potential customer base. But, this decision remains a complicated one.
In the previous post, I talked about getting this data from current users. But it is not only current users from whom data needs to be taken. To ensure that you are not dropping potential users from your customer base, you need to do surveys to determine whether your potential users are having an Operating System that you are planning to drop. Consider the case of Windows XP at this point of time. It is an old Operating System and you would might think that most users have moved on from Windows XP. But suppose you decided to drop support of this Operating System from your newer version and then suddenly see a drop in sales, it would seem obvious that you did not do the required survey of your potential users before making such a significant decision.
So what needs to be done ? Well, this is a survey of your potential customers, and is not as easy as just getting data from existing users. However, at the same time, there are many ways to get data related to Operating System usage. At any time, if you just do a search for Operating System usage, you will find that there are a number of articles where surveys have been done to determine the prevalence of Operating Systems among people worldwide, in specific age groups, across geographies and so on. So, if you have a product whose potential customer base is primarily among people above the age of 40 in the United States, there will be some industry data related to such a customer base. Of course, the data will not be exactly in the way that you need, so you need to account for the assumptions, look at the variables and then do an analysis to determine the data appropriate for you and use that as an input for your decision making.
However, it is not just looking at industry data. Another input for decision making is to call for a survey that looks at a sample of your user base and then provides that data to you along with a factor that determines the error assumptions in the survey. The advantage of this method is that you can determine the exact assumptions to be made in the survey, the queries to ask, and then get the results. However, to get accurate results and to ensure that you are not making inaccuracies, the survey needs to be thought through properly, and this can be expensive. But the science of surveys is pretty much standard, and you can be fairly confident about the results.
Now you have got the data required for your decision making, and you need to add variables regarding whether people who have older operating systems will actually buy your software, since people who are comfortable with their current software and operating systems are likely to have a lower percentage chance of buying newer software, even if it is very useful.

More information in the next post in this series (Deciding Operating System Support for your software - Part 4)

How to determine the Operating System support for your product - Part 2

In the part 1 of their series (Determine the Operating System Support for an application - Part 1), I started with the discussion about the various Operating Systems that product teams could support, and some of the complications that come about in the decision making for deciding the Operating System support. In this post, I will talk about some of the other issues that help decide what the operating system support should be.
One simple factor that determines what older versions of Operating Systems you should support include determining the customer impact if you drop a version. In today's day and age, you would be hard-pressed to find a user who has Windows 95 or Windows NT on their machines or an equivalent older version of the Mac OS. Even if you did find somebody like that, the number of people who are actually on such Operating Systems would be very small, and you should be able to afford such users. The tricky park comes with Operating Systems that are closer to the current version, such as Windows XP. Now Windows XP has had 3 newer versions of the Windows Operating Systems that have been available after that, namely Windows Vista, Windows 7, and Windows 8. But, a number of people (especially older people) do not make their software upgrade decisions based on whether a newer version is available. If a newer version is available, and if their existing version provides the functionality that they are comfortable with, you will find a significant % of people will not upgrade their Operating Systems or their machines. I personally know numerous people who heard bad stuff about Windows Vista, decided that their Windows XP installation was fine, and refused to upgrade. If your expected customer base has people who are like this, then it would be foolhardy to do an upgrade unless you are sure about your figures. And this is where things get tricky. You have to do data reporting and data analysis to get enough information to take a decision.
Now even inferring from the data analysis may not be fairly straight-forward. How do you decide the data collection technique ? You would want to know from 2 sources - one would be the current users of the application, and the other would be potential users. None of these are easy methods.
Suppose you want to get this data from current users ? The ideal way would have been to have a mechanism within the application that connects on a regular basis to your computers and provides some information about the computer of the user, including the Operating System and Service Pack version of the software application. If you were getting this information from all your users, then it is very easy to consolidate this information and quickly determine how many of your users are on the Operating System on which there is a query about whether you should continue to support it. Suppose you have set a benchmark of 10% being the limit above which you will continue to support an Operating System, then this data will easily help you make a decision. At the same time, keep in mind that building such a system in the application is not easy. In this day and age of security and privacy considerations, you would need to ensure that such a mechanism passes legal and privacy guidelines. Further, keep in mind that some of your users may not be connected to the internet on a regular basis and hence the data you get is only from those people who are connected to the internet. As always, when you get data, you need to make sure that this data is an accurate as you can verify. The method used for data collection, the logic used for the data interpretation both need to be accurate and verified, else you will commit the grave mistake of taking a decision based on either wrong data or wrong analysis of data, both of which can cause grave problems.

This is it for this post, will continue in this series in the next (Determine Operating System Support - Part 3).