Regression

When you fix one bug, there are 50% chances that you would introduce several* newer bugs. Thats a fact. Irrespective of how good programmer you are, Its very easy for a bug to crop in. Especially at the last hour, just before a release.

If a bug is found at the last minute and a quick-fix can be made by the dev-team. What would you chose to do?

• Fix the bug.
• Take it up in the next release, no checkins at the last hour. After all the qa-complete, regression tests and randomization/performance tests have been completed on a qualified build. Why take unnecessary risk of disqualifying/breaking any of it?

This is the dilemma every Dev-manager has to go-through.. Whether or not he/she choses to make the fix(or break the release!) depends on many factors.

Decision to fix the bug should not be on how easy the fix is. It should be on how crucial is the fix for the success of the product?

1. How many customers will it effect. If its one in four people(25%), than its a P1 blocker (P1-B). If its less than that, then probably the bug can go as a patch fix. Microsoft is famous for its SP1 and SP2 releases.
2. Is it something the user will notice right away (P1) or is it a usability issue with the product
3. Is there a work around?
4. Is it one of the input-types which fails validation? Can an attacker misuse it? If yes, then its P1
5. Remember how embarrassing the situation went for Bill Gates when Win-98 crashed right while doing its presentation (see Infamous Windows 98 crash ). Fixing that kind of bug is P1.

There can be other questions as well which a dev-manager needs to ask himself before the decision is made to checkin the fix.

Remember generally the gut-feeling will be that everything will work. Hence the decision should be based on some rational thinking rather than the gut-feeling. In my opinion its wise to be pessimist rather than an optimist..because Murphy is there and he is always watching…

“if anything can go wrong, it will.”