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 ..