University of Cincinnati

1
Teaching the Art, Science, and Psychology of
Debugging

• Russell E. McMahon, M.Ed

2
Russell E. McMahon

• Have over 25 years of teaching secondary,
  university, and business.
• Trained more than 1000 IT professionals from over
  100 companies while working for Cincom Systems
  and CGE.
• Mantis, SAS, JCL, COBOL, Basic, Visual Basic,
  HTML, SQL, C, C, C, Java, XML, EasyTrieve
  Plus, ROSPROCS, Assembler, Logo, Fortran

3
University of Cincinnati

• OMI College of Applied Science
• http//iet.cas.uc.edu/
• Information Engineering Technology
• NFS Grant 2 2 2
• Students enter junior year
• 2½-year BS co-op
• Computer Science Technology
• 5-year BS co-op
• Evening College Information Technology

4
Abstract

• Lecture -- address debugging early
• Lab -- students need to practice creating and
  finding bugs
• Homework needs to include buggy programs
• A students failure to debug a program failure
  of important concepts from being learned
  frustration ? learner and teacher
• Perception of ones code is just as important as
  knowledge of correct syntax.

5

• What insect runs away from everything ?
• A flee !

6
Research

• gt 50 of programming time is spent on debugging.
• http//www-h.eng.cam.ac.uk/help/tpl/languages/debu
  g/node1.html
• Only 20 of the time required to develop a
  program is spent writing the code 80 is used
  in debugging the software.
• http//www.galactic.com/Programming/articles/debug
  ging.htm
• Code Complete'' by Steve McConnell (Microsoft
  Press, 1993)
• Industry average for code production is 8-20
  lines of correct code per day.
• Industry average experience suggests that there
  are 15-50 errors per 1000 lines of delivered
  code.
• Recommendation design and code defensively
• For every 3 bugs fixed and new one is introduced.
• NIST -- Sw Errors Cost U.S. Economy 59.5 Billion
  Annually
• http//www.nist.gov/public_affairs/releases/n02-10
  .htm
• http//www.itl.nist.gov/

7
Research

• My Hairest Bug War Stories
• Marc Eisenstadt, The Open Univ., UK
• http//kmi.open.ac.uk/people/marc/
• Communications of the ACM, Vol 40, Issue 4, April
  1997
• He asked 3 questions
• What properties of bugs make them hard to find?
• How do programmers actually track down difficult
  bugs?
• What, typically, are the root causes of those
  bugs?

8
Research

• The Debugging Scandal and What to Do About It
• Henry Lieberman , MIT, April 1997
• Debugging is still, as it was thirty years ago,
  largely a matter of trial and error.
• What's wrong with the computer industry? I hope
  that this issue will convince you that one of the
  biggest "bugs" in the industry is the lack of
  attention to improving the tools for debugging
  programs.
• http//web.media.mit.edu/lieber/Lieberary/Softviz
  /CACM-Debugging/CACM-Debugging-Intro.html

9
Types of Bugs

• Syntactic (compiler catches these)
• Run-time (exception thrown)
• Logic (can take years to detect)
• Design
• Projects from Hell
• Shelfware
• Therac-25
• Inappropriate specifications implemented
  correctly or
• Failure to implement specifications correctly
• Debugging ! Testing

10
Syntactic Bugs

• Easiest to find and fix with todays IDEs and
  compilers.
• Compilers are very good at identifying error.
• IDEs make debugging very easy.
• Not all error messages make sense.

11
Run-time Bugs

• Most students spend their time here
• If it compiles, it must be OK mentality
• Why didnt the compiler catch this?
• Environment issues

12
Logic Bugs

• Hard to find
• Good testing plan needs to be in place
• Senior Design requirement
• HeisenBugs

13
What is a flea's favourite book ? The itch-hikers
guide to the galaxy!
14
The Art of Debugging

• Black art
• Secret art
• Creative art
• Its an art because of the constant changes in
  languages
• Instinctive -- follow your hunch

15
The Science of Debugging

• A systematic, changing one thing at-a-time
  approach
• Debug as you go
• Scientific method
• Hypothesis
• Code isolation and verify
• Correct
• Retest

16
The Science of Debugging

• Instructor needs to model good technique
• Desk-checking
• Use the IDEs debugging tools
• Documentation
• RTDM

17
The Psychology of Debugging

• Programmer know thy self and your compiler.
• Seeing the bug
• Building confidence
• What is in the book may not be correct.
• What habits lead up to this bug?
• Changing old habits
• Adjusting ones mindset

18
What is green and can jump a mile in a minute ? A
grasshopper with hiccups !
19
Lecture

• ASSUME
• Address all 3 areas of debugging early on
• Understanding what the program is supposed to do
• Pseudo-code
• Desk-checking
• Comment code
• How to use the IDEs debugger

20
Lecture

• Review bugs found in lab, homework, tests
• Version change issues
• What appears in a book is not always correct for
  the version of the compiler you are using.
• Resolving a bug problem is similar to solving an
  algebra problem.
• Frustration prevention

21
Lab

• Most students want/need guidance and practice in
  debugging
• Bug Team
• Students helping students
• Common Bug List
• Buggy code examples

22
Homework

• Discussion Board via Blackboard
• Buggy code practice
• Programming Learning Center
• Began January, 2002
• http//citcd.uc.edu/plc/index.htm

23
Tests

• 1st Test debugging part
• 2nd Test less debugging more coding
• Final all coding

24
Conclusion

• Problem-solving
• Knowledge organization
• Teach students how to limit their bugs via
  stepwise refinement
• Good coding techniques augmented with good
  debugging skills successful student
• Debugging costs companies time and money
• Agile Programming Techniques

25
What has 6 legs, bits and talks in code ? A
morese-quito !
26
References

• Russell McMahon, The Art of Debugging, Mantis
  Memo, Issue 4, 1988, Cincom Systems
• Chris H. Pappas and William H. Murray, III,
  Debugging C, Osborne/McGraw-Hill, California,
  2000
• John Robbins, Debugging Applications for
  Microsoft .NET and Microsoft Windows, Microsoft
  Press, 2003
• Everett McKay and Mike Woodring, Debugging
  Windows Programs Strategies, Tools, and
  Techniques for Visual C Programmers,
  Addison-Wesley
• M. Dehler, State of the art in code validation,
  Paul Scherrer Institut, CH-5232 Villigen-PSI,
  Switzerland, October 26, 2000

27
Journals

• Boies, S.F., and Gould, J.D. Syntactic errors in
  computer programming. Human Factors 16 (1974),
  253-257.
• Gould, J.D., and Drongowski, P. An exploratory
  study of computer program debugging. Human
  Factors 16 (1974), 258-276.
• Gould, J.D. Some psychological evidence on how
  people debug computer programs, lnternat. J. of
  Man-Machine Studies 7 (1975), 151-182.
• Youngs, E.A. Human errors in programming,
  lnternat. J. of Man-Machine Studies 6 (1974),
  361-376.
• Bill Curtis, Fifteen years of psychology in
  software engineering Individual differences and
  cognitive science, Proceedings of the 7th
  international conference on Software engineering,
  p.97-106, March 26-29, 1984, Orlando, Florida,
  United States
• B. A. Sheil, The Psychological Study of
  Programming, ACM Computing Surveys (CSUR), v.13
  n.1, p.101-120, March 1981
• Gilmore, D.J. (1991). Models of debugging. Acta
  Psychologica, 78, 151-172.

28
Websites

• http//www.drpaulcarter.com/cs/debug.php
• http//web.umr.edu/yongjian/cs238/stern/chap05.pd
  f
• http//www.cae.wisc.edu/help/handouts/pdf/general/
  debug.pdf
• http//www.cs.bris.ac.uk/Teaching/Resources/COMS11
  101/5_Debugging.p.pdf
• http//www.acc.umu.se/john/TAE/c002p06.htm
• http//www.cs.uregina.ca/hamilton/courses/110/pro
  grams/bugs/
• http//atlantic.evsc.virginia.edu/evsc503/slides/l
  ec20/tsld010.htm
• http//class.et.byu.edu/eet548/ClassNotes/debuggin
  g_story.htm
• http//www.drpaulcarter.com/cs/debug.php
• http//web.umr.edu/yongjian/cs238/stern/chap05.pd
  f
• http//www.csd.uwo.ca/jamie/C/HowToDebugC-Intro.h
  tml
• http//www.cs.rit.edu/icss232/debugging/debugging
  .html
• http//waynesville.k12.mo.us/Schools/WHS/DEPARTS/C
  ampCS/Debug.htm
• http//www.ii.uib.no/fredrikm/fredrik/debug/theor
  y.html
• http//www.csc.ncsu.edu/eos/users/e/efg/210/s99/co
  urse_locker/www/Notes/debugging/

29
Questions?

• Program testing can be used to show the presence
  of errors but never their absence.
• E.W. Dijkstra