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)

Emphasizing the importance of status meetings

During the course of a software project, there are so many different ongoing issues and sub-projects. As a result, there are so many matters that the project managers and leads do not know about; with some of the issues only getting highlighted when they are major issues or when they are close to bursting out in flame. There are team members who need information from other team members or need some help from outside the team, and they are not sure how to highlight this information.
How to handle such issues ? How do team managers and leads figure out all these and work out an ongoing formula to get more information, to provide information back to the team and to the layers in the team, and so on ? The answer to this is a version of the status meeting. This may be one meeting, or this may be multiple meetings, this may be a meeting the project manager has with the team, or this may be individual meetings that the leads have with their respective teams; or it may be a combination of all of these.
So, meeting(s) may be setup in the team on a regularly periodic basis. In such a meeting, you would have team members / leads / managers interacting on a structured basis, with issues being brought up, upcoming schedule milestones being highlighted, and so on. However, in a project, there are almost issues that may be on fire, or there may be other items that may be going on, where team members or leads may feel that it is more important for them to be present rather than attending these status meeting (this may be highlighted even further if the person has not had much going on in the previous meetings).
However, once this kind of a feeling comes in on the team, it can cause huge problems for the project manager(s) and the leads, since this meeting is extremely important for the team. As a result, right from the start, it is important to emphasize to the team regarding the need and necessity for this meeting for everyone in the team; that it would take something real critical to prevent people from attending this meeting. Some teams I know even make sure that if somebody is not attending the meeting or has not attended the meeting, they need to talk to a lead or a manager and explain the need for doing so.
And yet, there are cases. Team members visualize that this meeting is important for the manager, not for the individual team member; and it would not matter too much if they do not attend; or that they may something on their plate that is so critical that they can skip this one meeting. That last part may be true, but depending on the team dynamics and the maturity of the team members, deciding whether a team member can skip or not may be a decision that may be with the team member or with the manager. 

Defect handling: Rolling over bugs for a hotfix

Getting critical defects fixed before a software product is released. Right ? Would make a lot of sense, that the release would be considered problematic if there are fairly severe defects open when the product is about to be released. So I was so surprised when I was speaking to the engineering manager of a team which works on the regular subscription product updates release program for a software company (consider the case where a customer has bought a subscription, and every few weeks, the software automatically updates itself with a new incremental version of the product).
In such a case, the showstopper definition has changed. Now, the showstopper is not a severe defect, but anything that imperils the periodic release of the update; since customers have come to expect that there will be a release and may have their teams somewhat geared to handle and implement this release. In such a scenario, even though it seemed so odd that me the colleague was ready to accept a defect in the released product, that earlier might have caused the product release date to be impacted because of the need to accept the defect, analyse the defect and finally incorporate the defect fix. It took some amount of discussion with the colleague before I was able to accept the way their product release was setup to get impacted by defects.
The concept was that the regular updates have a rolling list of defects along with the update, and the customers have accepted this as a standard procedure, to the extent that they study the defect list and identify the ones that could impact them and pass these back to the product team along with a list of priority. This is the case with the multiple large teams that are customers. However, this is not to say that showstopper defects will not be fixed before the product is released. If there are defects that do not allow specific workflows to happen, or cause data loss or something similar that is of a severe impact, these defects will still need to be fixed before the product update needs to be released. However, earlier definitions of what is a severe showstopper would have been released.
A defect that would have earlier caused a product release to be delayed is now considered and evaluated as to whether it really something that is critical enough that it needs to be fixed now and cannot be sent out as a part of the defect list sent out by the product team. This relaxation, just as long as customers continue to trust the product team and its criteria, ensure that the team is able to increase its chances of  releasing updates on schedule which in turn actually benefits the team as well as the customers since it increased predictability.