Classic Tradeoff

As mentioned in another entry the classic tradeoff is: features vs. quality. A further refinement of this is: do you release a high priority feature even if it is not complete?

It is common for a project to bend to the pressures of client expectation and release a feature that may not be complete or is known to have defects. The thought that leads to this is that it is better to meet the expectation of the feature and deal with the quality risks later than it is to miss expectation. In my experience, the reality is the exact opposite. Releasing a feature with defects lowers the overall expectation of the product to a level much lower than that of a single missing feature.

Let’s take a look at this in more detail.

Releasing a product with a missing feature defines a single point of contention (i.e. the missing feature). The client will have a focused attack on the omission that tends not to spread to other features (unless of course there are other missing features). I have no theories as to why an omission does not spread — I only have experience that says that it does not impact the preception of the rest of the product.

Releasing a product with a defect heavy feature tends to lower the overall perception of the product. I believe that this follows a “If this feature has this many problems, then how bad is the rest of it?” progression. On top of this is the onslaught of defect reports (most of which are already known internally to the developers) that accompanies the feature. The amount of man power required to deflect or stop the barrage is sometimes greater than that required to simply fix the bugs. (Developers may be thinking “Just fix the bugs and ignore the client’s bug reports. Once the fixed version comes out all of the bug reports can be cleaned up en masse.” Unfortunately, it just doesn’t work this way unless the fix comes out a very short time thereafter. In most situations, the client hand-holding and expectation resetting combined with handling of the defect reports consumes needed resources.) I have seen projects where this barrage eventually stalls all progress and the entire team ends up in defect triage, changing focus from strategic to immediate tactical.

My recommendation in this situation is to take the omission hit and follow it up with a well planned and executed (and, if possible, ahead of expectated delivery) patch / release that includes the missing feature. If you botch the followup release, well, let’s just say that that tends to be worse than had the defective feature been released in the first place.

Advertisements

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