Today our customer reported a few high priority problems with our apps. My team lead had me look at one of them. Based on some business knowledge, alone with some screen shots of the error, I figured it out. After that I thought I deserved a lunch.After I picked up some take out, I found that a meeting was called to talk about the trouble ticket assignments. I thought I was safe because I knocked out a problem in record time. Nope. A guy on another team was having a hard time and needed help. I wanted to talk with him. But he was stuck in meetings all afternoon. I went with the one email he was able to send out.
I tracked down the processing that had occurred on the data. There was a lot of processing that looked missing. That was a good data point. I traced back the properties of the data and found out we were not supposed to do any processing due to some initial requirements. After I talked with the developer needing help, I found there were more examples of the problems.
I analyzed the data and confirmed we erroneously skipped some processing. At first my findings matched those of the developer. There was no way the code was going to skip this stuff. Then I recalled helping another developer on this team. He had some code that was loading variables in the wrong order. He fixed the code, but not clean up the data. The fix was also late to make it into production. Ouch.
Once I explained the history of the code changes, the light came on in the developer's mind. He said this explanation matched some other weird errors that got logged. I am thankful I knew about the work of the other developer (who has since left the company). Sometimes a little knowledge of past work goes a long way in bug tracking.
