"Never promise a release date" vs. "Release early, release often"

3 05 2005

Interesting discussion at micampe’s on software release policies. Basically, Michele is taking issue with one of the “Golden Rules” for surviving software projects:

Rule Number 1: Never promise a release date.

This is contrasted unfavourably with one of Open Source mantras:

Release early, release often.

My take on this is that both rules can be applied, depending on circumstances. Remember, there are no absolutes.

To put things in perspective, you should keep in mind the three variables that govern every software development project:

  • Time
  • Scope
  • Cost

(We might add “quality” as a fourth variable, but that should be a constant instead, valued 100%, as we all know that compromising quality in the hope of reducing time rarely works.)

As every good project manager should know, these three variables are not independent. A customer cannot fix scope (features) and cost while, at the same time, set an arbitrary release date.

Moreover, the relationship between cost on one side and scope or time on the other is never linear. If you are late, you cannot usually go quicker by adding more developers.

With these facts in mind, consider a project where a customer is demanding a given set of features and is not willing to compromise on them. In this situation it is very dangerous to commit yourself to any release date. You won’t be able to stand by your commitment, that’s a fact.

Admittedly, this is an extreme situation. Unless you’re developing software to be put onboard a space probe that must be launched in a very specific time frame, when all the necessary, planetary alignments are in place, it’s usually the case that those features that the customer says she just can’t miss can be scrapped without too much pain. Scope can almost always be negotiated.

And when scope is negotiable, I agree with Michele that it’s better to release early, release often. This approach is the same as is advocated by XP: choose a number of stories at the beginning of each iteration and no matter how many of them you have actually implemented, never move the end of the iteration.

See also the description of “Timebox Development” on Steve McConnel’s Rapid Development (p. 575).



2 responses

3 05 2005
Berin Loritsch

They can both be practiced without issues. “Never promise a release date” is much more nerve racking if you don’t release early and often. My take is that you never promise a release date, you just release regularly. You can recommend specific releases to your clients, but as long as you don’t promise feature X will be here by such and such a date then you can work steadily toward it.

4 05 2005
Robert McIntosh

I don’t see how “release early, release often” is promising a release date. Quite the opposite, if you release often, you don’t have to promise a date, because your users/customers will know another release will be coming.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: