Click here to Skip to main content
13,191,040 members (74,811 online)
Click here to Skip to main content
Add your own
alternative version


14 bookmarked
Posted 12 May 2003

Software Debugging Process: How it goes and how to improve it

, 23 Jun 2010
Rate this:
Please Sign up or sign in to vote.
The process of debugging: formalization & improvement


Of course, everyone has heard about RAD, RUP, CASE, iterations, waterfall, etc. and some people are even experts in these things. But wait! Software developers also need service and support, the most important part of which is debugging. Who knows what percent of development effort is spent in debugging during the whole software life-cycle? You can find estimates in various articles and books, but it's apparent that the percent is high! Unfortunate, but that is the reality...

In this article I'm trying to describe the process of debugging, generalizing my experience. Debugging is a less formalized activity than development and I would like to change that, since one of advantages of formalizing a process is the possibility of improving the process. I will also give some suggestions on improving the debugging process based on its formal description.

The Process

Unlike software development, debugging is inherently iterative. (I mean development in general, realizing that in complex projects development can and should be iterative, too). Debugging, in general, consists of three main stages:

  1. Describe the bug.
    Maybe this isn't part of debugging itself, but it's so important that I include it here. You should get as much detail from the user as possible: product version, OS version, all conditions needed to reproduce the bug.
  2. Get the program snapshot when the bug 'appears'.
    Try to reproduce the bug and catch the state (variables, registers, files, etc.) and action (what the program is doing at the moment, which function is running). Sometime this is simple: e.g. the program crashes and you can just switch to your debugger to see the problem. But in other cases you have to perform many iterations to catch the snapshot. You maybe even have to return to 1 in some cases. In other cases you will return here from the next step.
  3. Analyze the snapshot (state/action) and search for the cause of the bug.
    It is possible that the state and action might be wrong, so a substep in this stage is to determine whether they are correct or not. The following state/action combination classification can be useful in guiding further analysis ('+' & '-' indicate 'correct' & 'wrong', respectively ):
    • +/+ : unreproducible bug;
      You have an incorrect description or different environments (OS, etc.)
    • +/- : a simply found bug;
      You have to add some checking (NULL pointer, divide by zero, etc.) or additional implementation of something
    • -/+ : a bug requiring a search for its source, origin;
      Methods you can use include
      • tracing from previous moments,
      • tracing of places where the state components are used/changed
      • tracing with different input data
      • your experience may indicate key places in the program (e.g., the start of user input processing)
    • -/- : same as -/+ plus additional difficulty, but due to the difficulty of situation in some cases some work-around may be enough decision, i.e. making action correct (+).
  4. Fix the bug.
    Ideas about bug fixing may occur at any stage of the debugging process, but only one may be implemented, which 1) fixes the class of bugs which the described one belongs to, and doesn’t introduce other bugs in other places and/or with other input data.

Experience and knowledge of the program play key roles in all stages of debugging. This knowledge can help both in getting the program snapshot and searching for the bug's origin. Examples of key places to look include the start of user input processing, multi-functional procedures, etc. Therefore the following ideas can be useful to keep in mind.

To Improve Debugging

  • Build smarter debugging tools. Since these tools would be used in almost all stages of debugging, it would be useful to “teach” them the program and the program itself should help debuggers.
  • Create a system/DB of key documentation about the program useful in debugging, for example "If there is a problem in aspect A, then look (set breakpoints, etc.) in key places A1, A2, … ". The DB should support searching.

Have a nice Debugger! :)


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Web Developer
Russian Federation Russian Federation
This member doesn't quite have enough reputation to be able to display their biography and homepage.

You may also be interested in...


Comments and Discussions

SuggestionBug Finder Pin
Antonio Petricca7-Jun-13 1:50
memberAntonio Petricca7-Jun-13 1:50 
GeneralVery good! Pin
cristitomi4-Jul-07 5:25
membercristitomi4-Jul-07 5:25 
GeneralEditing, better treatment Pin
Mike Dimmick20-May-03 22:27
memberMike Dimmick20-May-03 22:27 
GeneralRe: Editing, better treatment Pin
diamant20-May-03 23:07
memberdiamant20-May-03 23:07 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.171016.2 | Last Updated 23 Jun 2010
Article Copyright 2003 by diamant
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid