BugFu: The art of finding and fixing bugs

From WackyWiki

Studies show Software developers spend approximately 50% of their day debugging. The best way to reduce this is to increase code quality offcourse. But when you are confronted with crappy code, here are some tips to help you find and fix bugs faster.

• Record and classify the problem

When an user reports a problem, it means there is a difference between what happend and what the user expected. So, make sure you record the expected result. Also check the specs; is this a defect or feature request?

Keep a debugging logbook.

• Reproduce the failure

If you are not able to reproduce the problem, you cannot observe what is going on. This thoroughly limits your ability to reason about the program. Basically, your only chance is to deduce from the program code what might have happened to cause the problem.

You may be able to deduce a potential problem cause - and even to design a change that would fix this potential cause. But how do you show that your change actually fixes the problem in question? You can do so only by reproducing the initial scenario with the changed product, and showing that the problem now no longer occurs. Without reproducing the problem, you can never know that the problem has been fixed.

Automate and simplify whereever possible

• Locate the defect; this is by far the most time consuming of all debugging activities

Find possible infection origins by followin back the dependences from the failure to possible infection origins

Focus on Anomalies / Code smells. These could be triggering a defect. Trace back the defect and/or isolate the various anomaliees to rule them out as a root cause.

Continue isolating origins transitively until you have an infection chain from defect to failure. Use things like logging or debuggers to observe where the program state becomes infected

• Correct the defect or provide workaround. Sometimes correcting a defect is difficult.

The program in question cannot be changed-for instance, because it is supplied by a third party and its source code is not available.

The correction induces huge risks-for instance, because it implies large changes throughout the system.

The problem is not in the code, but in the overall design-that is, the system design must undergo a major revision.

• Verify fix by rerunning reproduction test

If the program still fails after your correction has been applied, though, there is still a defect that must be fixed. It may well be that a failure is caused by multiple defects, and that removing the first defect causes the second defect to become active.

However, there is also a chance that the code you fixed was not a defect at all, and that your understanding of the infection chain was wrong. To exclude this possibility, work through your earlier observations and experiments, as noted in the debugging logbook. Check whether your conclusions are valid, and whether other conclusions are possible.

If you conclude that the defect might be elsewhere, bring back the code to its original state before continuing. This way, your earlier observations will not be invalidated by the code change.