CertPal

It was a normal day. The sun rose, birds were singing and everything seemed to be going fine until Kaboom ! A bug appeared in the live environment. Things turned downhill from there that day. But we are more interested in how things got fixed so lets focus on that.

An investigation of the code revealed that the bug had crept in because of a minor mistake. A variable was referring to the wrong column index on a table. ‘Hmmm… simple fix’ I thought. I told my manager it would not take more than 5 minutes to do. ‘Its a one line fix’. Mistake.

There were loads of other things to do after fixing this bug. This is what I ended up doing over the next 4 hours.

• Analyze if any other code flow would explode.
• Code the fix – This only took 5 minutes as expected.
• Move fix to DEV
• DEV server crashed. Great. Fix this and get DEV up and running.
• Test fix
• Export the old data before the fix
• Export the new data after the fix
• Compare new data with old data and verify the result for each column (Wrote a small program to do this).
• Move fix to PROD
• Close the bugzilla bugs and fill in a lot of bug details
• Inform PROD users about the fix

So ! There we are. All done. Loose ends tied. But at the end of the day, I had not set the right expectations when I went about fixing this problem. When you say things like ‘It will be done in 5 minutes’ and ‘It is a one line fix’, you need to remember that to an end user / manager that might sound something like ‘It will start working again after 5 minutes’. But that is not the case. Well… a manager with a technical background would be more understanding but that is not my point.

Sometimes there are things you cannot put down in writing when you provide an estimated time to fix stuff. I find it is always better to say ‘Sometime by Tuesday noon’ instead of ‘One line code change / 5 minutes’. It sets the right expectation and you don’t have people asking you ‘Its not done yet !?’. Explaining your work is sometimes more important than the work itself.