While development needs a methodical approach and a good developer can always be in control of what he is coding, bug fixing in most cases appears to be a more dynamic activity. There are several reasons – the original code may have been written by someone who is not available, an unfamiliar component, non-reproducibility of the issue, vague or even lack of information, too much unrelated information, hard to meet deadline and the list goes on… However, in my experience of fixing (or killing) hundreds of software bugs I have seen that in most cases one can apply a methodical approach to fix issues.
1. Do not be afraid of bugs, or rather, code that seems obfuscated to you. If someone could write it, you are capable of understanding it. The only factors are time and honest effort. Some bugs need more than usual time and effort to understand in the first place. Put the word through to your boss stating the technical difficulty as you understood it. There’s no shame in taking time to fix a bug if you can build a confidence on your capabilities (through your track record) that you seldom fix the same bug twice.
2. Read through the problem statement multiple times till you understand the scenario. If you are not familiar, discuss in the team to understand what else you need to understand the scenario. Request to get the information and try to get it in one shot. In many cases, customers or testers get irritated when a developer asks repeatedly for different sets of logs, tests etc. Understand that they have their own work which is equally important to them as your work is to you. If feasible, ask for the original setup so that you can get what you want remotely and independently.
3. Once you are done with the scenario, now it’s the time for the analysis. There are two kinds of bug fixers – patchers and pros. Patchers look for quick solutions and are prone to break other things or leave behind related issues while fixing one thing. Pros fix all related issues once and for all. The best way to start is to identify which part of the code is related to the problem (the problem region). Then track back to the places where that code is invoked (fan-in) and understand why. Next go through the problem region, go through each line checking for the root cause and at the same time mapping is to your brain. If you find the root cause, great (and for most issues you will find it in this step, for example – condition misses, segfaults, wrong logic etc.); otherwise move on and get and idea of the fan-out of the problem region. Do this until you get the whole flow mapped to your brain. This exercise also helps you in saving time when the next bug in the same area comes and develops your understanding of the design of the whole product – issue by issue (in addition to the development you do).
4. Now it’s time to think. Start eliminating the fan-ins and fan-outs based on your observation of the logs and symptoms you checked in step 2. At one point of time you will be left with a subset from which you can’t eliminate anything. Time to get your hands dirty – add more logs, reproduce, use the debugger if needed and isolate the scenario. This needs patience, sometimes a lot!
5. Once step 4 is over, you know where your problem is. Now it’s time to think of code changes to fix it. Go back to the flows you understood in step 3 and think of the best possible solution that won’t have any side effect. Think on what else might need to be fixed along with the issue in hand. This judgment comes with experience. If not sure, discuss with your team. Make changes only when you are confident.
6. The fun is not over yet! You need to do your testing. Based on your analysis in step 3, think of the scenarios that you may need to test. Take your time, make a list and write them down. It’s often a great idea to add this list in your bug tracking tool before you change the status to FIXED. Test the scenarios. If you find time is insufficient to test the full list, take help of the tester involved in the issue or even the customer. In most cases they will be more than happy to help you when they know that you are doing your best. Once you are confident of your changes, check-in and post it.
Throughout this phase, be driven by a single motto – no problem should ever have to be solved twice (from How To Become A Hacker). This will give you enough energy to fix a bug the correct way – the pro way! In addition, as you keep fixing bugs your knowledge of the product design will keep increasing which will help you learn how to design as well as how to enhance weak designs.