Our customer reported a strange problem in the production environment. They were not seeing the right display on some data. The guy who leads my team took this problem. He asked me if I knew how to make the problem happen. I did not. So I recommended he get in touch with the user that submitted the problem.A tester on our project also called me and asked if I knew how to make this problem happen. I told him I did not. This tester and my team leader got together to work on this problem. My team leader consulted the documentation. Then he tried changing the test data in our development environment. However he was not able to replicate the problem that the user was having.
Once again my team leader asked me for some advice. He thought that perhaps this was some sort of screen resolution problem where text is getting clipped. I told him this might be the case. However I urged him to consult the source code that computes and displays the value. After all, you should not trust the documentation 100 percent.
A few minutes later, the team lead called back. He saw that there was some transformation in the source code that resulted in the data being displayed on the screen. He was then able to make the behavior happen in the development environment. Usually once we can recreate a situation, we can resolve the problem. The hard work is getting to that point.
I am frequently surprised how developers in the maintenance world are hesitant to call up the end users and trace the actual source code. They often concoct all kinds of theories as to what might be wrong with the system. The problem is that until you know exactly what the user is talking about, and you see the code that is involved, you might go nowhere with the hypothesis method.
