Agylen

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