As I have said before, debugging is a complex and time consuming process. I have outlined 10 resources for debugging, and provided a primer for things not to do when debugging. Now, we get to the meat and potatoes of debugging. This is a guide of things to do when debugging. I have broken this guide into three sections – a description of the Scientific Method of Debugging, Tips for Hunting for Bugs, and Bug Prevention Methods.

Scientific Method of Debugging

This is a parallel to the Scientific Method that you learned in your grade school science class. The book Code Complete by Steve McDonnell outlines this methodology to debug your applications.

• Stabilize the bug by identifying the simplest test case that reproduces the error
• Locate the source of the bug
  • Gather data about the bug and its behavior
  • Analyze the data regarding the bug
  • Form an hypothesis about the bug
  • Write test cases that would prove or disprove your hypothesis
  • Run the tests and prove your hypothesis, or begin again with a new hypothesis
• Fix the defect
• Test the fix with all of the new unit tests you have written
• Continue to look for similar, cascading, or peripheral errors

For a more detailed breakdown of the Scientific Method of Debugging, read Code Complete by Steve McDonnell.

Bug Hunting Tips

These tips for finding bugs, broken out into different areas, will help you narrow down where your bug is.

General Tips

• Be sure to save the original source code
• Be sure the fix the problem, not the symptom
• Make one change at a time
• Check and Double Check your fix
• Consider the possibility that the bug is generated from multiple sources
• Divide and Conquer
• Check other places where bugs have existed
• Check other places where code has changed recently
• Compile the application again

Logging

• Insert Trace, Print, or Alert Statements to help track the bug
• Create a logging methodology to trace the application
• Check the Log Files of the servers, etc.
• Search the web for the stack trace

Unit Testing

• Design By Contract
• Write unit tests that cause the error
• Try to reproduce the bug in different ways
• Try boundary cases and special cases

More Complex Methods

• Recompile with a different compiler
• Create a mini version of the application
• Sequentialize the Parallel to see if it is a timing or resource issue
• Try the code in different environments (local, dev, test, prod, other developers’ machines, etc.)
• Grab someone else to talk through the bug without looking at the code (explaining the problem may trigger some ideas)
• Do a full, in-depth code review on the broken code

Last Resort

• Rewrite the whole section of code that is causing the bug
• Take a break for a few minutes, or an hour, or until the next day, to give your mind time to process the data

Bug Prevention Methods

These are things that you should be doing during the planning and development of your applications that will help you identify, fix, and test your bugs after you are done with development.

• Identify and track consistent bug types within your own code
• Introduce debugging methodologies early
• Implement loose coupling techniques
• Implement Information Hiding Techniques
• Write a regression test that tests the bug you just fixed

So… these are some different ways to attack debugging. Are there methods that have proven themselves that you have used? Do you take a different, more unique approach to debugging? What have your experiences shown to be your best practices? Please leave your feedback and let me know what you think.