I got a call from my team lead. He said another developer was having problems fixing a bug discovered by the customer. This other developer thought he found some code that was suspicious. So he made some changes hoping that would fix the problem. This scenario was easy for me to analyze. If the guy could not duplicate the problem, he sure as heck did not fix it. It is simple as that.
This problem got reassigned to me. Like everyone else who could not replicate the problem, I tried to check out the behavior. It seemed to work. But I know that is not the end of the story. I went to peek at the production data. Then I recreated records in development that matched production. Finally I followed the steps the production user was taking. I encountered the bug.
I will admit this was a tricky bug. The software seemed to work for the trivial case. But you had to have some certain properties set for the initial record, and you had to navigate to another record that was different than the initial one. We had a couple teams try to recreate the problem. They were unsuccessful. Once I determined the steps required to recreate the problem, the fix was just a couple lines of code away.
Here is the lesson learned for maintenance programmers. You must be able to recreate a problem before you can do any more work on it. If you cannot do this, you have no business making any code changes to fix the bug.
Backtrack Linux - Backtrack is a Linux distribution based off Ubuntu. It is used for penetration testing and forensics. The distro was a combination of WHAX and Auditor. It...