Objectives of Debugging

Effective debugging requires that you have a goal in mind and that you know where you're going. Equally important is knowing why you are doing it and whether you should even be doing it at all.

Computer people sometimes fall into the trap of believing that everything can be solved by coding. That's the way we are trained, recognized, and rewarded. Many of us have gone into the computer business to avoid having to deal with people. You get the attitude of "just give me the source code and I'll fix it."

Sometimes, though, someone needs to step back a bit and decide if it really needs fixing. Maybe the system is old and outmoded and really should be replaced with more current technology. Maybe the system itself is the main problem. Maybe the users need more training. There are a lot of different problems not related to code that can be the real underlying cause of system difficulties. Only by having definite objectives in mind can you be effective in debugging not just individual lines of code but entire computer systems.

Fix the Problem

This is the most immediate and the most simplistic objective that most of us have when beginning to debug a problem. It's broken. Fix it.

Different people and different organizations may have wildly varying definitions of this, ranging anywhere from applying a quick-and-dirty fix to going through the full ISO 9000 quality process. In some cases, this definition of "fix it" includes such approaches as:

• Deny that it exists.

• Blame it on another vendor.

• Blame it on the operating system.

• Blame it on the user.

• Find someone else to do it.

• If all else fails, try to patch it up enough to just get by.

While the items listed here are very much tongue-in-cheek, the reader will probably recognize times when she has either used one of these approaches or had it used on her. It's important to remember how you felt when someone used such a tactic on you. This is exactly how your customers or users feel when they get it from you. Not a very productive approach, and certainly not a way to build long-term respect. Each of these approaches is likely to cause you more trouble and take more time than doing it right in the first place.

A real fix will:

• Solve the immediate problem as soon as possible. In a production system governed by time constraints, this may entail a quick fix or workaround that stays in place until a permanent fix is made. In this case, be sure that the process doesn't end with the quick and dirty solution.

• Be a long-term solution.

• Ensure that the problem stays fixed. All systems go through a life cycle of releases and upgrades. Unless the problem is corrected both at the source and on-site, the next upgrade or revision of the software will contain the same problem, and either you or someone else will have to solve it again. Make sure that you fix a problem only once.

• Correct similar problems in the system. If you're debugging a program and find that there is an error in the logic or in the code, the odds are that there will be similar errors either in the piece of code you are working with or with other code written by the same programmer or programming team. The first time you see an error is the best time to poke around and see if it exists in other places. Doing this will allow you to leverage your time.

Placate Angry Users

There are three major times that you will be presented with a debugging problem. You may recognize a bug while developing code yourself. You may discover a bug during the testing and validation process. Finally, you may find a bug after the code has been deployed. In the first two cases, you probably won't have to deal with angry users. In these cases, the debugging process is simply an extension of the coding and testing process, and you'll probably be working on code that you wrote yourself. If anybody's angry, it will probably be you being angry with yourself for making a stupid mistake.

If the bug is discovered after the product is deployed, you're facing an entirely different set of circumstances. Dealing with end users requires at least as much skill in psychology as in debugging. You will find yourself debugging more than just software. You'll be debugging problems with attitude, with respect, and with confidence. You really need to expand the concept of debugging to cover these intangibles because these intangibles are ultimately more important to success than any code problem.

Knowledge Transfer

This is not a first-level objective in most debugging tasks, but it should always be an eventual objective. Every time you discover and fix a problem with a system, it presents you with an opportunity to teach others and to teach your organization how to avoid similar problems in the future. This requires some sort of formal or informal process for feedback within an organization. This is where bug-tracking databases and knowledge bases can be useful.