Iterative Releases

Yes, iterative releases, you read it right. We always hear of iterative development, agile process, etc. These methodologies describe processes for iterative development of a software. While these processes describe different approaches to developing software, they all typically assume that a software major release comes packed with new features that the team has worked on for an extended period of time.

Now consider the following typical release cycles: you released version 1.0 of your product; you then released version 1.1 with mainly bug fixes; you may also have released version 1.2 with some minor features.

While working on these minor releases, you have gathered your requirements for version 2.0 from different sources and are ready to start design and development for your next major release. Your initial estimate predicts a 6 to 9 months development cycle. Taking into account testing, beta cycles, etc., your next release should be ready in about a year. Depending on the methodology you adopted, your requirements are broken down into stories, use cases or just milestones with several iterations that are typically 2 to 4 weeks long. For the purpose of this article, I will refer to these are feature sets. Now consider this approach. You work on the first feature set, design it, develop it and test it. You then package it as version 2.0 and release it to customers. You continue through your development iterations and at each iteration, you release a minor version 2.x.

The main benefit of this approach is that you avoid the 1 year release cycle which is detrimental in many ways. Why you may ask?

1. First, your are forcing your customers to wait until all your features are developed to start benefiting from them. Some of the new features may be critical to retain customers and you run the risk of losing them. 2. For new customers, if you are lacking critical features that will only be available in a year, you have lost them. 3. A 1 year release cycle is quite long. The productivity of developers is usually at its peak when the feature they are developing is planned for immediate release to customers. 4. Because completed features will be available to customers at every iteration, issues will inevitably be reported soon after release forcing the developers to fix these issues promptly. This will ensure a continuous bug fixing process as opposed to leaving all bugs until the end which leads to a highly unstable product. What are the drawbacks of this approach? We believe this approach is ideal for small development teams (1-3 people) working on relatively small projects. For larger projects that involve larger teams, the logistics behind a release are too important and expensive to repeat at every iteration. Process automation is key in making this a success. For this approach to work effectively, you would ideally have a fully automated build process, automated unit tests and system tests. As bugs are found, you may be forced to release many versions of your product and run the risk of having too many versions out there. This can become an issue when dealing with backward compatibility. Finally, this approach will require customer education. Customers will get a shock when you release a new major version of your product with just a few features. They will ask questions. You need to be prepared to answer them and preferably, prepare them by explaining your process. As you guessed, customer education is what this blog was intended for as we prepare for the release of Quick License Manager 8.0!