Learn Software Development » Patch http://learnsoftwareprocesses.com All about the processes involved in software development Thu, 15 Jul 2010 18:51:14 +0000 en hourly 1 http://wordpress.org/?v=2387 Product Development – Rolling out the patch http://learnsoftwareprocesses.com/2008/09/28/product-development-rolling-out-the-patch/ http://learnsoftwareprocesses.com/2008/09/28/product-development-rolling-out-the-patch/#comments Sun, 28 Sep 2008 09:35:30 +0000 ashish http://learnsoftwareprocesses.com/2008/09/28/product-development-rolling-out-the-patch/ The previous post had thoughts on what are some of the conditions under which a software patch is typically required. Once the decision has been made to make a patch, there are a set of activities that are needed to be done. A patch typically is a miniature version of a complete product development cycle, not with all the activities, but certainly having many of the steps that one needs to carry out in the typical cycle. What are some of these steps that are needed to be done ?
- Decide on which of the fixes need to make it to the patch: When preparing a patch, there is always the temptation to fix all the issues that have been found after the release. However, beware of feature creep. You should only include fixes on the patch that are deemed critical. Putting other fixes means that the time period for the patch becomes longer, it means that QE needs to out more effort to test the patch, and so on.
- Make sure that all the teams are signed up for this patch. For a moderately sized software company, there will be multiple teams (with their specialized functions) that are needed to make the patch. These include the development team, quality testing team, configuration team that is responsible for the installer and release, localization team (if there are multiple languages involved – this is another decision point, whether the patch needs to be rolled out for all languages), marketing teams to ensure that patch publicity plans have been rolled out, web teams (if the company website is maintained by another team, they need to involved so that they can schedule the patch rollout date into their plans)
- Decide the schedule of the patch. Even though this is an abbreviated release, it will still take time, and the further this time pushes into the schedule for the next release, the more impact that this patch will have in terms of creating problems for the next release.
- Decide on branching strategies. Typically teams need to make sure that the source code repository has a proper branch created to handle the new branch for the patch. In most cases, the entire team will not be involved in making the patch, and so the work being done by the rest of the team for the new version will be on the main branch, and the work being done by the engineers working on the patch will be on the separate branch. A strategy also needs to ensure that the defects being fixed on the patch will be integrated with the main branch once the work on the patch is done.
- At the time the work on the patch is being carried out, if the patch is due to some major customer issues or some security issues, then the marketing and management of the team need to decide whether to release news of an upcoming patch. Typically, news of patches are not released earlier, but sometimes such news can help in calming down customers who would otherwise be worried.
- Development work for the fixes that go into the patch will need to be done. This typically involves a thorough engineering investigation into the issues that need to be fixed as well as working with outside partners if the issues needs such cooperation
- Once the fixes are made, they need to be thoroughly tested by the QE team on the different platforms on which the software is supported
- Now the patch is ready, and needs to be rolled out through the different media that can be used. The patch can be mentioned on the company web site, on the product page, in customer support forums, to product users directly if there is the ability to send software users a notification inside the product, via email to all the registered users, show as an update to users if the app has the ability to do an automatic check for updates.

The next post will talk about minor (dot) releases and the difference between a patch and a dot release.

]]> http://learnsoftwareprocesses.com/2008/09/28/product-development-rolling-out-the-patch/feed/ 0 Product Development – Doing a patcher or a minor release http://learnsoftwareprocesses.com/2008/09/25/product-development-doing-a-patcher-or-a-minor-release/ http://learnsoftwareprocesses.com/2008/09/25/product-development-doing-a-patcher-or-a-minor-release/#comments Thu, 25 Sep 2008 18:34:17 +0000 ashish http://learnsoftwareprocesses.com/2008/09/25/product-development-doing-a-patcher-or-a-minor-release/ When doing the planning for a new version of the product (not typically applicable when creating a new product), it sometimes becomes necessary to consider the case of doing a patcher or a minor release (also known as dot release).
Picture this scenario – your product development team has already started planning for the features that will be implemented in the new cycle. They are trying to get an initial SWAG (literally means a Wild Ass Guess, but is typically used to define when experienced development managers and engineers do a rough guess of the amount of resources it will take to develop a given feature), are working with Product Management and User Design to get some more details of the initial feature requirements such that a more accurate estimate (but still rough estimate) is available. In the middle of this, if they are suddenly confronted with the need to plan for doing a patch or a dot (minor) release, it can take away a fair number of resources and affect the schedule for the next version.
So why does a team end up doing a patch or a minor release (dot release) ? Let’s talk about a patcher first.
Reasons for doing a patcher:
- Easiest reason. After releasing the product, you discover a bug (through internal testing or from customers) that is liable to affect a number of customers. So, suppose you are doing a printing application, and you find that printing of Excel documents does not happen properly in common cases, this is something that cause you to do a patch. There is a high priority that a number of customers will get affected by such a problem.
- Crashes. A slightly more difficult situation where a number of customers have reported problems where the application suddenly crashes. On diagnosis, you find the root cause of the problem and decide that the risk of customers getting the crash is not very low, or there is a high risk of important data loss when the crash does happen. This is very important for certain classes of applications such as financial and enterprise applications.
- Customer / Tech support issues. There are a variety of issues that are not important enough to warrant a patcher on their own, but together they are causing problems with a high frequency of customer support issues and tech forums posts. Because all of these have a cost (and a lowered reputation because of many customer posts on forums is not easy to recover from), it is sometimes important to admit that there were mistakes made and release a patch.
- Device dependencies. Support you are a maker of a photo software, and many new cameras are released (or you discover problems with some existing cameras), it is important to project an image that you are responsive to developments in your field and are providing updates to your customers.
- Adding some important new operational functionality. This is a slightly tricky area since the recommendation is not implement new functionality in a patch, but if you have some important new functionality that needs to be implemented in as many existing customer apps as possible, then this is something that seems permissible. For example, if you get a new component that allows you to provide customers with a new and easier update mechanism, it makes sense to provide such a functionality through a patch available for wide download and use
- Dependencies on other software. Nowadays most large software applications also internally use other software components. For example, video players will use external codecs, CD burning software will use device burning codecs from Nero or Sonic, and many other such examples. If you find that your dependency is going to cause problems unless you install a newer version of the external component, a simple way is to incorporate such changes in a patcher.
- Competition. Your competition is going to release a new version of their software that gives them a competitive advantage, and your development process means that you cannot release a new version quickly enough. A workaround is to make the changes in a patch and make that available to your customers.

This post is turning out to be longer than I thought, so the process for deploying patches as well as the development of minor releases will be covered in the next post ..

]]> http://learnsoftwareprocesses.com/2008/09/25/product-development-doing-a-patcher-or-a-minor-release/feed/ 0