So you are relatively new to software development and you are presented with one of the most difficult bugs to resolve. What do you do? Where do you begin to look?
In my experience, when this occurs less seasoned developers will do one of the following:
- immediately give you a possible source of the problem
- immediately write more code to attempt to identity the problem
- Agree to have a solution by the end of the week and make NO progress.
Why is this?
One thing I always remind my colleagues is that software development is a science, even though there are some who feel this is an art. Let me repeat this, software development is a science. So, in the field of science, how do we solve problems? Do you remember the “scientific method”? Developers should utilize the scientific method to solve software problems. The 6 steps of the scientific method can be utilized to ease the pain of debugging and increase your likelihood of success.
1. Ask a question
When presented with a bug you MUST ask questions to get a clear understanding of the problem. Within this phase you want to understand all aspects of the problem. In most cases, problems that exist in software are not random. Therefore your goal in this phase of the problem solving process is to remove the random nature of the problem and find the predictable nature of it. Below are few key questions that will assist you in your findings:
- When does it occur?
- What behavior are you experiencing?
- Can you consistently reproduce the error?
- Can you recreate this issue in a different environment?
2. Do background research
Take each answer to the questions asked and analyze or verify the information given. Be sure to evaluate the environment or any other specifics that will allow you to make better assumptions. This information should be used to assist you in formulating your hypothesis.
3. Create a Hypothesis
Your hypothesis is what you think the root problem is based on your understanding. At this point, you should fully understand the problem and make an educated guess to where the source of your problem may originate from. This can only be done by leveraging your research to read through the code and better understanding what is being executed.
4. Test your Hypothesis
At this point you will understand all the details of this problem. Take your hypothesis and find the areas within your code that support you hypothesis and begin to put breakpoints in the appropriate places in code. By running the code within the debugger you can view the execution of the code and inspect variable values as well as the execution paths.
5. Analyze your Test Results
Based on the results of your test and debug sessions, review the information that was gathered and the execution path of your test. Determine if your test cases are valid.
6. Accept or Reject your Hypothesis (Draw your Conclusion)
At this point you should fully understand the problem and should be able to accept or reject your root cause hypothesis. If your hypothesis has been proven, begin formulating a plan to fix the bug. If you hypothesis is rejected, start over at step 1 until you are able to find the root cause of your bug.