Supporting previous versions of the software (Part 5)

In previous posts in this series (Supporting previous versions of the software (Part 4)), we have talked about how an organization makes the decision to remove support for a (much older) previous version of the software. Removing support means that customers are encouraged to move to a higher version, defect fixes are not provided and the support team will not take any more calls on that version. This can get tricky, and sometimes the decision is not all that clear as to whether the support would be withdrawn.
For removing support for a previous version of the software, the groups that typically advocate removing this support are the development and testing teams; the number of previous versions of the software that remain supported in the market, the more effort they need to put in. For example, just as an example, there are a lot of compatibility issues that need to be developed and tested, and these increase as the number of previous versions are supported. Another example would be the support team, since they have to keep a track of issues, defects, notes, and other items for all the previously supported versions. However, when you look at product management and marketing, they have a lot more contact with customers, and they are able to better figure out whether it is possible to drop support or not.
I am going to try to layout some reasons where the team took the call regarding whether to drop support and decided that they cannot drop support as of now. Here are some of the reasons (and this cannot be a comprehensive list, more based on my experience in the industry).
- Too many users complaining about support being withdrawn: This happens when the team informs people through support forums and the helpdesk that they are planning to drop support. If there is significant push back (and discussions with some those protesting reveals that they are really going to be impacted), then the organization may decide to not drop support as of now.
- Previous deals commit support for an extended period of time: This happens typically in the case of OEM's or when there is a large deal. As part of the deal, support was required for 5 years after the launch of a version, and this grew tricky in the years to come. But we were bound by this condition, and the only learning was to be more careful of the implications of providing support for extended periods of time.
- The Product Management / Marketing looks at data, looks at support discussions, user forums and decides that the level of discussion is still fairly high enough that the support needs to remain for some more time.
- Data from metrics reveals that the understanding of the team was incorrect regarding the number of people still using the software and the data reveals more people that are using the software. In this case, it could still mean drop of support along with an offer for those people using the older software to get some concessions when they are upgrading to the latest version.

Read the next version of this series (Supporting previous versions of the software (Part 6))

Lining up the support structure at the start of a cycle with firm commitments ..

During the course of a software project, you need the support of a number of people. For those who are not so well versed with the various challenges involved in project management, handling the support and resources from outside the core team are one of the biggest challenges during the early stages of the project, during the middle of the project, and during the later stages of the project; which only means that handling the various supporting teams is one of the biggest tasks during a project cycle.
So consider the starting time of a project. The features that are required for the project to succeed have been generated (including the trade off about the ones that are critical for the project vs. the ones that can be cut when there are schedule risks), and there is a need to ensure that there is a formal kick-off for the project. What do you do in a formal kick-off ? Well, one of the key items is to ensure that the team knows what the project is about, what are the key features that will be there in the project, and other such details. Typically the product manager will give a presentation to the team about the aim of the product, the market, the revenue earned by previous versions of the product and the target for the current version, and a high level description of the features that are sought to be included in the project. For many of these features, the further detail that the product manager can give is about how these features were derives, whether these be from competitor analysis or specific requests by customers, or generated based on ideas by the team.
However, as part of the initial kick-off, there are many other discussions that need to take place. For making the software development project successful, there is a lot of support that is needed from other teams. There are teams that prepare the build and the installer, there are teams that work on the documentation and help files, there are teams that deliver components that are required for specific functionality in the product, there are teams that work to translate the product in other languages. Most modern organizations have these kind of dependencies; it is no longer possible to have a situation where a single team does everything that is required for the team (for example, if you have a product that uses video formats, you would rather be using a common component that uses different video codecs to work with these formats rather than write code for working directly with these video formats (it may not even be possible to write code for all these video formats due to technical and commercial limitations)).
It is easier to ensure that you have the support of your core team and more difficult to ensure that all these supporting teams are providing the required support. For this purpose, before the kick-off, you would need to work with all these teams, providing them details about your requirements and the schedule in order to get a commitment from them (in some cases, where there is a clash due to priorities for support, you may need to escalate before you can get the desired commitment). In all cases, unless you can get the required level of support from these teams in terms of commitment, your project is already at a certain amount of risk that you will need to manage in one way or the other.

Using freely available Youtube videos as part of help for your product ..

When a software development team produces a product, the help for the same is critical. The software may be incredible, but if people do not know how to use it, then the software is of no use. And for every user who is an expert in using the software, there would be 2-3 more who get lost in some part of the software or the other, and are only dependent on the manual or information available on the internet for how to use features within the product. For this purpose, the team spends a fair amount of time to ensure that the help manual is descriptive, and is easy to read. Further, it has to describe the workflows with the minimum of technical verbiage, in most cases meant to appeal to the starting user, and describe all the workflows that are possible in the application (which can make reading a detailed product manual a difficult task). However, even though there are a lot of jokes about people no longer bothering to read the manual or refer to its electronic version on the web site of the product, there are still a large percentage of users who do refer to the manual, and hence companies do ensure that they spend the requisite amount of time on preparing the manual.

There have been changes in preparing the manual over a period of time, or rather in the content. Earlier while there used to be a focus on text and some images, nowadays, there is an increasing focus on also including video tutorials and explanations on different features. Users are very comfortable with seeing video tutorials, and are more easily able to grasp than if they were looking at written text alone (what this means is that the existing text tutorial would be supplemented by video tutorials). However, to prepare video tutorials is much more expensive than text. It takes much more money to prepare a video tutorial (we are not talking about a tutorial prepared by a team member using a handycam - it needs to be more professional), and it is much more expensive to also convert a video tutorial to different languages that the product is released in (if somebody is speaking, then the video may need to be shot again or a voiceover given, or sub-titles used; similarly if screen shots are used in the video, then the video needs to be modified to use screen shots using the language version of the product). Hence it is not an easy matter to think of a number of video tutorials even though it is very useful.

I know some companies that have come up with a way of reducing this cost, but not eliminating it. The company would still create video tutorials, but for a more specific set of workflows, ensuring some reduction in cost. For any product that is somewhat famous, there will be people who have created tutorials for different features and workflows and hosted them on Youtube and other video hosting sites. The company can reach out to such people and talk to them about pointing a link to these video tutorials inside the product for different workflows and features. A lot of people will just be thrilled that the product is linking to their tutorials and will agree (of course, the linking needs to have a step in between where the company can ensure that if the Youtube link goes bad, they can modify the link inside the product to point to a different site). There may still be problems about language versions of these tutorials, but if there is a different tutorial available for the same feature in another language, the language version of the product can use that tutorial - there is no requirement that the same tutorial be used in the language versions of the product.

Making sure that all methods are used to inform users about patches or dot releases ..

A patch or dot release is typically done by a product team for defects or some improvements that the team would have made over the past period of time. Most people are familiar with the concept of Service Packs released by Microsoft for Office, Windows, and other tools that it has. So a service pack would typically take a number of improvements and defect fixes and make them available for users to download and install on their machines. A patch release in turn is meant for defect fixes that have been deemed critical enough to provide a fix to users. A service pack is typically meant to be a large patch, combining a large number of fixes and optimizations for the application. A dot release is a slightly different animal. Typically, in my experience, a dot release is when the code of the previously released version of the application is taken, the fixes are all applied to the source codes, and a new version of the application is released. This new version of the application is now ready for use by customers; if the released version of the application was 7.0, now the team can take the 7.0 code, add the fixes to the code, and then release a version called 7.1. This new version, with the fixes, replaces the previous version 7.0, and is the version that is available to consumers.
So, now that you have a new version, or a patch, or a service pack, how do you get this to your users. You would want all your users to take the new version, for multiple reasons:
- If you have fixes for problems available in this release, then with customers adopting such a release, there will be lesser need for support for such issues.
- If you get all your customers to adopt such a release, then it is easier to provide technical support. If you have customers having different versions of software such as 7.0 or 7.1, then it gets more complicated to provide support for such cases. In such cases, it would be easier if all customers have the 7.1 version.
- When you provide a new version post 7.1, it would be easier if you have most or all customers on the version 7.1. When a new version 7.2 is releases, there would be need to provide support for customers to upgrade from versions 7.0 or 7.1. When you have software such as Windows or Adobe Reader, on which there can be a number of service packs or patches released, this kind of upgrade support can make things difficult.

Now that we have the background, how can you increase the chances of more people taking the new patch or release ?
- Spread the information about new releases on the company site. As an example, if you take a large company such as Adobe, it has a section of the site called Updates (link). On this site, all the downloads and patches for different products released by the company is listed. Other large companies also follow a similar practice.
- Use social networking to spread the word. Most popular products have their presence on Facebook or Twitter, and companies should release information on these updates along with details of the major changes, and how to install the application.
- Seed support services such as consumer forums, user forums, customer support services, with information about the updates; for customer support, calls on major defects that are fixed with these updates should tell customers about the same.
- Nowadays, most major products have an update service, and the update should provide information to the customers about the desirability of the update and why the customer should do an update of the product.
- And now for a more forceful approach. Over a period of time, in order to ensure that everybody was on the update, product teams have actually terminated support for those users who are not using the latest patch. As an example, Microsoft a couple of years back stopped providing support for those users who were not on the Service Pack 2 of Windows XP.
All these techniques are important to increase the proliferation of updates among the application users.

What are features of Hyper-Threading technology?

The HT technology or the hyper–threading technology is a proprietary SMT (simultaneous multi–threading) implementation developed by Intel in order to make improvements in the pluralization of the computations that are carried out by the microprocessors in PC. It was first included in the Xeon server processes and then in Pentium 4 processors, atom, Itanium, core I series etc. Two logical or virtual cores are addressed by the operating system for each physical processor core present. The workload is shared among these two whenever required and possible.

Features of Hyper Threading Technology

1. Hyper–threading technology reduces the number of instructions in the pipeline that are dependent in nature. This is also its main purpose.
2. Architecture: The hyper – threading technology is based on the super scalar architecture. This kind of architecture is capable of operate multiple instructions in parallel with separate data. It appears as if there are two processors, thus letting the OS operate with two processes simultaneously.
3. Resource sharing: The same resources can be shared by the two or more processors available. Re–allocation of the resources can be done up on the failure of one of the processes.
4. Support for SMT: Hyper–threading implies the support for SMT through an OS that is SMT supportable. The OS needs to be specially optimized for this technology. It is recommended by Intel to disable the HTT if the OS have not been optimized for HTT.
5. Two processors: Certain processor sections are duplicated by the HTT. These are the sections in which the architectural states are stored. The main execution resources are not duplicated. Because of this, the HT processor appears as two processors to the OS namely, the physical and the logical processor. So the OS is able to process two threads at the same time without messing up. When a current task is not using the execution resources and the HTT and when the processor is stalled (because of data dependency, cache miss or branch mis-prediction), those resources can be used by the HT processor in execution of some other task scheduled earlier.
6. Support for SMP: SMP stands for symmetric multiprocessing which is mandatory for taking full advantage of the hyper – threading processing.
7. Transparency: There is a lot of transparency between the OS, its programs and this technology.
8. Easy optimization: HTT allows easy optimization of the behavior of the OS on HTT capable systems running on multiprocessors.
9. Provides support for multi–threaded code thus improving both the response time and reaction.
10. Application – dependent performance: It works well in improving the performance of most of the MPI applications. The improvement in the performance depends largely on the nature of the running application and its cluster configuration. The performance gain can also be negative. Using performance tools would be beneficial for understanding the factors contributing to performance gain and degradation.
11. Security: A timing attack can be used by some malicious thread for monitoring the other thread’s memory access patterns. This is nothing but the stealing of the cryptographic info. This can be avoided by changing the cache eviction strategy of the processor. 

The hyper – threading technology has been criticized heavily for being energy inefficient. It has been stated by ARM that power consumption in SMT is more than in the dual – core designs by a margin of 46%. It was also claimed that cash thrashing is also increased by a margin of 42% in SMT when compared to a 37% decrease in the case of dual core processors. However, on the other side, Intel has claimed the HTT to be highly efficient since it puts the ideal resources to use. 

How is test driven development and documentation linked?

As we all know that the test driven development or TDD is another process in the list of the most of the popular software development processes. The topic of the test driven development is in the league of this article. 

About Test Driven Development

- The test driven development took its root from the idea of the repetition of a very short development cycles. 

- The first of all a failing automated test case is written or created by the software developer or tester which is meant to serve the purpose of defining a new function or a desired improvement. 

- Secondly a code to pass the above created test is also written by the developer. 

- This newly written code is then subjected to refactoring in order to make it meet the acceptable standards. 

- The test driven development has always been looked up as an encouragement for the simple designs and also as an inspiration for boosting up the confidence levels.

- The test driven development has always been known to be related to the concepts of the extreme programming or XP. 

- But, eventually it came to be known as a standalone process having its own ways and rights.

- The concepts of the test driven development are used by the programmers and developers as a measure for debugging the legacy code and improving it further. 

- The test driven development is usually driven by a series of automated unit tests that are written by the developer to provide definition for the requirements of the code and then the code is automatically produced. 

- These tests are constituted of the assertions of their own.

- If a test is successfully passed, the developer is confirmed of the correctness of the code and that it can be further evolved and refactored. 

The documentation forms a very important part of any development or testing and so does of the test driven development. This article has taken up the question: “how is test driven development and documentation linked?”. 

About Importance of Documentation In TDD

Now coming to the importance of documentation in the test driven development, it includes the following documents:

1. Feasibility report
2. Technical documentation
3. Operational documentation
4. Log book and so on.

- The documentation in test driven development is another source of support to the developers as well as the users.

- It provides all the crucial information required to set up a uniform environment in which the software system or application is to be operated. 

- In case of a break down when the person in charge is not available, the users experience down time and most of their resources are wasted. In such situations, there is only one thing that can save one’s precious time and efforts and that thing is nothing but the documentation. 

- It provides all the information and guidelines that are required to fix an issue. 

- The format of the documentation does not matter much as much as it content matters.

- Documentation is vital to any software development process and not particularly to the test driven development.

- Documentation is an effective mean for streamlining the test driven development process. 

- Apart from all this, documentation has got an important role to play in the business.

- Document is needed in the test driven development since it helps in codifying the procedure for the development of the software system or application. 

- The documentation provides effective protection during the audits to the test driven development.

- It is important that the documentation is developed alongside the development of software system or application. 

- Documentation will be effective if it is considered to be a part of the work and not a hindrance to it.