What can make our releasing easier? Perhaps not surprisingly, quite a bit - the challenge is to influence the appropriate parts of the process.I hope to provoke some thought and give some pointers to more detailed explanations of individual ideas and references.
What is a Release?
My definition is getting a version of "the system" into the hands of the users, where the system may be one or more executables, web pages or web sites, associated documentation and help, related backend or third party systems, associated support systems, embedded systems, etc. The system needs to be something that works and that performs valuable functionality for those users. A release of the system "on the shelf" is about as much use as a chocolate teapot.
For many internal systems, organisations would benefit tremendously from treating it as a product development for external use, which typically have higher standards applied to them.
Common Release Problems
From the view point of the business, releases frequently:
- take too long - a new release which misses the market opportunity may miss millions in potential revenue.
- are unpredictable - one of the best diagrams I saw about the advantages of CMM showed the predictability of project schedules
- coming down from an average variance of 30 weeks to a variance of less than 4 weeks over a 2 year period as the organisation moved to level 2. One example I have come across is Symbian. They produce the operating system to go in millions of mobile handsets. Software release dates are planned in to schedules including factories making those handsets. The cost of unpredictable or missed schedules is potentially massive.
- have poor quality - systems with too many support calls and too many bugs. The impact on public trust caused by bad releases can have a very long-term effect. Look at Microsoft's efforts with " Trustworthy Computing "  and other related efforts to improve public perception of some of their products (though other factors are of course also present in this case).
- are not useful - does the system actually support useful functionality needed by the business, or is it mainly technical bells and whistles?
The business typically wants to manage risk sensibly andgain the maximum advantage from releases.
There are many other problems with releases, such as:
- contents of the release not being planned - the contents are produced in a rather ad hoc manner with all code finished by a certain date integrated in some fashion and shoved out the door.
- contents unknown and uncontrolled - I have seen many systems where people did not know exactly what had gone in to particular releases. I know of one company producing a fairly widely sold tool where they had very loose "controls" on releases. They didn't know what had gone out the door to various customers, and which variants were in the field. Myriad versions lay around which might or might not have been released. Support and reliability were a nightmare.
- distribution/installation - frequently overlooked areas, or at least overlooked until too late. A system that can't be got easily into the hands of users and installed on their system is not terribly useful. Upgrade/downgrade are also vital considerations.
Making Releases Easier
Let's look at what we can do to make releasing easier.
As with most things, the better we plan, the better the end result is likely to be. So what activities do we need to plan? Well if we consider the typical lifecycle of software products, it contains activities such as:
- Identifying the Business case and gathering requirements (market/features)
- Detailed Design, Code and Test