Notes on “Debugging: a review of the literature from an educational perspective”

June 10, 2009

Debugging: a review of the literature from an educational perspective: McCauley, R. et al.

A survey of debugging literature dating back to 1973, targeted at teachers of programming.

It covers:

  • Differences between novices and experts
  • Categories of bugs and causes
  • Mental models of programming and debugging

An informal definition of debugging:

“we define debugging as an activity that comes after testing where we “find out exactly where the error is and how to fix it.””

Debugging questions:

  1. Why do bugs occur?
  2. What types of bugs occur?
  3. What is the debugging process?
  4. How can we improve the learning and teaching of debugging.

Why bugs?

– Breakdown between goals and plans

Novices: Novice understanding of program constructs

  • Data type inconsistencies
  • Natural language problems (natural while vs. prog. while)
  • Expectation of intelligent interpretation

Otherwise: 7 main causes of bugs

  • Boundary (Off by one)
  • Plan dependency (misplaced code in control structure)
  • Negation and whole part (misuse of logical constructs)
  • Expectation and interpretation
  • Duplicate tail digit
  • Related knowledge interference problems
  • Coincidental ordering problems

Novices have fragile knowledge. Four types of fragile knowledge:

  • Missing: Never acquired
  • Inert: Fail to retrieve when needed
  • Misplaced: Used in the wrong context
  • Conglomerated: Bad combination of constructs

Anoter categorization:

  • parallelism: different lines of code executed simultaneously, e.g. ‘while’ problem
  • intentionality: Expect the program to be smarter than it is
  • egocentrism: Assume more meaning exists in the program than actual

Ko and Myers 2005 to be summarized when I actually read that paper.

Hand-made novice bug catalogue in Johnson 1983 and Spohrer et al. 1985

What kind of bugs?

Most bug categorizations listed are on novices. Exception: Knuth. But his is an introspection.

Gould 1975: Which kinds of bugs are hardest to find? Bugs in assignment statements.

What types of knowledge are aids in debugging?

  • Program output
  • Good variable naming
  • Program comprehension

Or, from Ducasse and Emde 1988:

  1. Knowledge of intended program
  2. Knowledge of actual program
  3. Understanding of implementation language
  4. General programming expertise
  5. Knowledge of application domain
  6. Knowledge of bugs
  7. Knowledge of debugging methods.

All good debuggers are good programmers, but not all good programmers are good debuggers.

What strategies are employed in debugging?

Tactic-based: Gould 1975

Choose and use tactic, leading to clue, bug or neither. If clue or neither, form new hypothesis, select new debugging tactic.

Hierarchy of goals: Vessey. Complete strategy path.

A six-step process: Determine the problem; gain familiarity with the program; explore program control; evaluate the program, leading to hypothesis; repair error.

Katz & Anderson 1987: Three different techniques for finding an error

  • Forward reasoning program order (program simulation order) (Good, used mostly on unfamiliar programs)
  • Forward reasoning serial order (program code order) (Bad)
  • Backward reasoning (work backward from output) (Good, used mostly on familiar programs, i.e. own code)

Ducasse and Emde global strategies:

Filtering, checking, checking well-formedness, bug recognition

How do novices and experts differ?

Experts much better at program comprehension, therefore debug faster, better.

Experts and novices: Similar activities

Novices introduce bugs with their debugging attempts. Experts much more surgical.

The paper also covers implications for education, which I don’t care about.

%d bloggers like this: