May 1, 2010
Introduction to Debugging
Through these posts, Debugging tips are going to be introduced. But first why Debugging?!
The reason is simple . . . Software has bugs.
Unfortunately, it is true. Even the good old “Hello World” program can be considered to be buggy.
Developing software means having to deal with defects; old ones, new ones, the ones you created yourself, and those that others have put in the code. Software developers debug programs for a living.
Hence, good debugging skills are a must-have.
We are going to start with generally applicable hints which should not be neglected. We are going to start with the “13 Golden Rules of Debugging“….
1. Understand the Requirements
Make sure you understand the requirements before you begin to debug and fix anything.
2. Make it Fail
You need a test case. Make your program fail. See it with your own eyes
3 .Simplify the Test Case
You do this in order to
• rule out factors that do not play a role,
• reduce the runtime of the test case and, most importantly,
• make the test case easier to debug. Who wants to deal with data containers filled
with hundreds or thousands of items?
4. Read the Right Error Message
Something went wrong and you face a screen full of error messages.
Which ones do you focus on?
It is surprising how many people don’t give the correct answer.
The ones that come out first!
So, first things first – fix the problems in the order of appearance, or have a very good reason for breaking this rule.
5. Check the Plug
Next, check the seemingly obvious. Were all parts of the software up and running when the problem occurred? Permissions OK? Enough disk quota?
Think of ten common mistakes, and ensure nobody made them.
6 .Separate Facts from Interpretation
Don’t jump to conclusions. Maintain a list of things you know for a fact, and why.
Ask yourself: “Can you prove it?” Is the behavior reproducible? Is what you consider a fact really a fact? “It fails when I select a blue item but it always works for red items” a bug report may state. So misbehavior depends on the color? Maybe not. It could be that the user selected the blue item with a mouse click and everything else via the keyboard, by specifying its name.
7 .Divide and Conquer
The National Institute of Standards and Technology defines divide and conquer as an algorithmic technique to “solve a problem, either directly because solving that instance is easy [. . . ] or by dividing it into two or more smaller instances.” And further “the solutions are combined to produce a solution for the original instance.”
This strategy can be successfully applied to debugging in order to deal with complex situations when multiple factors can play a role.
Hint: In the next post we will describe one possible divide-and-conquer approach.
8. Match the Tool to the Bug
Some debugging tools (like GNU) are easier to use than others in a given situation. But not all are equally helpful. It is natural to focus on the tools and processes you feel most comfortable with.
9. One Change at a Time
Do not change more than one thing at a time if possible. Then check if it makes sense and, if not, revert back before trying out the next idea.
10. Keep an Audit Trail
Often you will have to deal with a problem involving multiple parameters. You need to try out a number of combinations. It is all too easy to lose track of your changes.
Keep an audit trail!
This is especially important in the case of spurious failures.
11. Get a Fresh View
When you are stuck, go and find somebody to talk to. Make sure to draw a clear line between the facts – and why they are facts – and your theories. The process of explaining the situation to somebody else may help you to separate truth from myths.
12 .If You Didn’t Fix it, it isn’t Fixed
Occasionally, a bug will just disappear after you modified some statements. Unless you have a good explanation why your fix is effective, you are better off to assume that the bug still exists and will hit again in the future.
13. Cover your Bugfix with a Regression Test
So the problem is fixed . . . today. What about tomorrow? To make the bug fix last, you should turn your simplified test case (rule number3) into a regression test. Think of it as a safety bolt. It prevents others with access to the source code base from accidentally breaking a feature you have put quite some work into.
The term regression test means something along the lines of “check whether yesterday’s functionality is still working well today.” These tests should be automated in order to allow for frequent and efficient execution. And the tests should be self-checking.
Those were our tips for this week. Wait for tips about “Unit Tests and System Test” in the next week 
