Fog Creek Software
Discussion Board




Release Candidates

I was wondering if people can share their experiences in releasing consumer products - what schedule milestones should one follow.

It very tempting and automatic to set up a product release schedule that shows a single date when the product will be available. But what are the correct intermediary steps to follow? Is it

- beta
- release candidate(s)
- general availability
- follow up patches

What are your definitions of each of these steps. Although the above sounds reasonable - is this what Microsoft does with their products? Are they a good example?

The reason for these questions is that we just want to fall out of the regular traps of optimism, and inject reality in the project and release schedule that is proven by other organizations.

Or is this a simple problem that has already been solved and documented in development books? If so, what are the books?

Thanks.

teek dwivedi
Tuesday, October 22, 2002

Your release schedule is never proven by other organisations. Unless they have already made what you are now going to make. But even then, one example is hardly a statistic.

If you're looking for a magic bullet, rest assured, there are none.

You should also realise that a development process is vastly different from a construction process. The latter would be based on past experiences of similar constructions. For instance, people have been building walls for centuries. It would be easy to find out how long you would need to build a wall, given size and strength, and a typical builder.
But, building the wall is only a very small step in development. Essential, no doubt, but not representative for the activity. Unless you have not been prepared well enough.
Unless you already know exactly what you are going to build, defining what you are going to build is going to determine your activities. And it is a lot less clear how you plan that in detail, if you can at all.

So instead of focussing on when you are going to be ready, focus on what you are trying to achieve instead. And find out what you need to do that, but also what freedom you have in doing so.
If you already know that your product must be ready in a year, you focus on what you can make in a year.
If you know what you need for the product to be successful, you focus on how much time you need to make that.
In reality, you'll have to compromise on both time and features.

But in the end, define the goals you are trying to achieve, and adjust you milestones to them, because the milestones are merely a tool. That must fit your work, not the other way around.

Erik
Wednesday, October 23, 2002

It very tempting and automatic to set up a product release schedule that shows a single date when the product will be available. But what are the correct intermediary steps to follow? Is it

- beta
- release candidate(s)
- general availability
- follow up patches


I'm a bit worried to see "beta" and "release candidate" both "follow" the product available date in your thoughts. I'm sure you don't mean that the way it reads.

Microsoft's product development cycle is a bit more involved than your example of it above would reflect. If you decide to follow it then you need a proper model of it, but I'm going to suggest you think about what actually reflects your needs rather than copying microsoft's schedule.

Do you really need the public betas they do with big products, for example? If you do, what will the difference be, to you with your products, between a release candidate and a beta. Will your users actually give a damn?

Robert Moir
Wednesday, October 23, 2002

*  Recent Topics

*  Fog Creek Home