Fixing a bug under severe time constraints

Question

Recently I had to fix a bug that was reported from the field. While the test team was trying to reproduce the issue, the customer was breathing down our neck and we had to have production ready code in just a week's time. When at last when we were able to reproduce the issue there was just 3 days left. I and my colleague had to put in almost 30 hours of non-stop effort in finding the cause and having the fix in place in the code that wasn't written by us. Luckily we did it. However, my concern is that the test team didn't have enough of time to run through their usual test cases. And we had to overlook other trivial mistakes in the code to limit the code changes.

I would like to know from the community the best practices to follow in such time-critical conditions. Is it okay to neglect other issues (which aren't causes for the bug you are working on)? How to limit the code changes, that too in legacy code, as much as possible such that I need not worry that only minimal testing is possible. Continuous work without any sufficient breaks can also add its problems. Please share your thoughts and experience.

Answer 1

There's already some great advice here, but I'd like to add something else:

If you just crank out a bug fix under extreme time pressure, remember to come back and look at that fix when the pressure is off to make sure it isn't just a horrible hack that's a bandaid over a real problem.

Back in the late 1980s, I fixed a bug that was way down deep in a very old program. But it wasn't working right under one case that used to work. When I investigated further, I found that a "temporary" work around had been put in place. The comment said:

C TEMPORARY WORK-AROUND UNTIL I FIND THE REAL CAUSE.  I CHARNY, SUMMER STUDENT, AUG 1971

Irv Charny was my boss when I found this 15+ year old "temporary work-around".

Answer 2

One best practice is obvious don't "Continuously work without sufficient breaks"

Another is put you commercial head on and use some common sense, what is the risk you have introduced another as serious or more serious bug? How will the customer react to that? How will the customer react if you explain your need for more time? Weigh the answers and make a commercial/executive decision.

Answer 3

One best practice is obvious don't "Continuously work without sufficient breaks"

Another is put you commercial head on and use some common sense, what is the risk you have introduced another as serious or more serious bug? How will the customer react to that? How will the customer react if you explain your need for more time? Weigh the answers and make a commercial/executive decision.