Debugging 100

Universities typically title their introductory courses XYZ 101: Introduction to XYZ. Often, the 101 courses require that students have some basis of knowledge in the area (e.g. pre-algebra for a math 101 course, or some level of writing skills for an English 101 course). Where I went to school, these “pre-intro” courses were “100” courses – e.g. Math 100: Pre-Algebra.

I was recently asked to prepare a short course on debugging for a group of recent college graduates. The catch is, that none of them graduated with a computer science degree. They know some programming, but probably (imo) not enough for me to dive right into a laundry list of debugging tools and techniques.

As I was thinking about this, I realized that a lot of developers are too dependent on the tools. I have observed dozens (if not hundreds) of debugging sessions where developers stared at the code (or assembly) in the debugger looking for a hidden clue, or stepped meticulously through the code, only to miss the moment when their precious variable changed values. I’ve worked with developers who refused to look at a bug (or even think about it) unless it was trapped in the debugger. Debugging tools are one part of debugging, but I decided that I will talk about the other parts of debugging.

Simply put, debugging == isolating the problem. That means that to improve debugging skills, you need to improve skills on problem isolation. If your car won’t start, what do you do? You could outsource (call a mechanic), or you could debug. If you decide to figure out why your car isn’t starting, you are going to try to isolate the problem. You will want to examine the symptoms (is the engine turning over or not), the environment (is it cold, hot, do I smell gas, do I have gas), and historical variables (when was the last time it started, has this problem occurred before?). Once you’ve thought about these things, then you should bust out the appropriate set of tools (jumper cables, gas, oil, tire iron, …) to help narrow things down. To me, these steps make perfect sense when thinking about a car that won’t start, but I see developers (including test developers) ignore this when trying to track down a bug.

Tags:  ,

Comments (4)

  1. Anonymous says:

    I enjoyed the book "Debugging, the 9 rules…" ( in large measure because it took the same aproach you described, thinking, theorizing, testing, observing, and thinking some more. Good insights in your post!

  2. Anonymous says:

    simple, clear and crystal. Good job!

  3. Anonymous says:

    I have a couple of posts lined up in addition to this, but while doing some blog maintenance I discovered