Last week has been a firefighting week at work (i.e. debugging and troubleshooting). I’m writing this article to share my experience with debugging a system configuration at work. In the end of article, I have placed some lessons learned points so hopefully someone can learn from it to improve their career.
Today was a good day at work. There was a spike card was mentioning about a bug that was occurring at random actions. However the QAs have found that behavior to be specific for a section of the application.
Given the spike card work to track down the cause of this bug was set to 1 day, we manage to find the cause and also fix it with precise thought and action nearly under a 1 day. We do pair programming at work and this was a card that brought me high amount of personal satisfaction after finishing it and exceeding the expectations we set.
The work-flow went smooth for this card. The analysis and tracking the bug was excellent with great communication with the pair partner in my opinion.
I think I have applied some important rules mentioned int he book “Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems”. It is an excellent book to learn how to track bugs.
Additionally an important rules we applied before start working on the card was to diagnose the bug. Meaning that I wanted to get any information that our QA team and product manager knew about this bug. Questioning the behavior makes it easy to isolate where the bug is hiding. Without this initial information, it will add more time to build the information by testing the system by the developers.
Another thing I applied was my intuition. I really like to apply my intuition (as those thoughts come naturally to me) though most of the time it doesn’t work. But when it does, I get a very high satisfaction. How I applied intuition here was like this. Considering the behavior of the bug, I remembered another developer had finished a card in the realms of the bug recently. So I needed to refer the changes of that card in order to find a relation to the bug. By comparing the changes required by the card, I felt there is a significant impact from whatever code changes made by that card to the bug. And it was.
At the end, the bug was not remembering to unbind a specific event. So in one line the bug was fixed. However our precise analysis and smooth work-flow helped to find this bug and fix it quite quickly.
- Do your detective work. Ask questions from the colleagues to get to know more about the bug
- If it is a new bug, see what features or changes done recently and intuitively think if there is a connection. If you believe so, check it out but don’t spend too much time on this. Also this point would not be ideal for everyone.