Comments on: Can We Teach Debugging?

By: JCS

JCS — Thu, 13 Aug 2009 07:29:11 +0000

Great “tutorial” on how to solve bugs. The key point is (in my opinion) follow a structured way. Creation is usually messy, but the approach to debugging must be structured.
After several frustrating attempts when I was a kid, I stop assembling those projects from the Electronics magazines. Later I understood that if don’t know what is “happening” you shouldn’t build it.
As you I, learned a lot from mechanics, after graduation I worked for a lift (elevator) company, we designed the controllers and worked mostly with induction motor drives and hydraulic lifts, now I solve problems in my bike :-) When you are faced with problems in complex systems requiring interaction of many parts on different domains (mechanics, lubrication, hardware and software) you need to approach the problem in an analytical way: isolate a section; check if it works as it should; if so check the other section, if not break this section again. If you don’t proceed methodically you’ll be lost in the jungle and you’ll never leave.

By: jet

jet — Mon, 10 Aug 2009 05:06:38 +0000

Limor, your instructions are a rare exception in the kit-building world. You not only explain what to do, but why to do it, so kudos to you for your efforts.

By: limor

limor — Mon, 10 Aug 2009 02:03:06 +0000

while i of course agree that kit building is not the same as studying from a book, it does provide a structured way of seeing -patterns- of electronics, eg “There always seems to be a diode between a 7805 and DC Jack” “LEDs have a 1K series resistor”. much like following a recipe does not mean you’re a cook, but eventually many basics sink in.
the real learning comes when the user modifies the kit!

By: Mark

Mark — Sun, 09 Aug 2009 23:06:39 +0000

I loved the analogy to diagnosing a car. I still vividly remember the day I was trying to fix my car and couldn’t figure out what was wrong. My dad, who happened to be an electronics engineer, came along and started breaking down the problem of “my car won’t start” into appropriate sub categories, in this case air, fuel, and fire. There was no obstruction of the air intake, and valve timing was fine. Pulling a spark plug, I cranked the engine and observed a spark. Finally he pulled the hose off the fuel pump output and we saw that there was no fuel pressure when the engine cranked over. As this was one of the last times I saw my father, I still remember this incident every time I feel stumped trying to debug something. My father taught me how to think things out by his example. The science is in knowing what experiments to try, the art is knowing how best to do the experiment and which experiments to do, but the real key is knowing how to think. Sadly, that usually gets lost in the maze of facts and figures. What’s really needed is a teacher, a guru, who has realized the differences between cause and effect. This can be anybody anywhere: a parent, a teacher, a co-worker, or even a timely stranger. We just have to be willing to get past our fear of ignorance and earnestly seek the answers we need. Once you reach that point, the guru will appear, though you might not recognize them as such. One of the greatest things about on-line forums is the way total strangers can share problem solving strategies and fill in missing knowledge about various subsystems.
Does anyone remember back in the 80′s when there was a huge amount of hype about expert systems? People hoped then that expert level skills could be boiled down into a set of rules which a program could simply run through in order to solve a problem, but none of those programs knew how to ask a new question.
Yes debugging can be taught, but it is an empirical knowledge gained through hands on experience, not simply a memorized procedure. You have to learn how to ask the appropriate questions in order to get the appropriate answers, and that is not a simple thing.

By: Jeffrey

Jeffrey — Sun, 09 Aug 2009 15:51:53 +0000

I think another thing to throw in along with “isolate the problem” is “Is there a problem at all?” Many so-called problems are just misunderstandings of what proper behavior is suppose to be.

Somewhat related is problem definition. “It doesn’t work” isn’t sufficient, of course. Iteratively defining The Problem in deeper and deeper detail tends to reveal the underlying “why?” This tends to involve some research and self-education – a step in the process that some get paralyzed at. This was the hang up VCR owners had years ago – programming a VCR was A Problem To Solve and it required that you had to learn something new. And that is where people gave up, stopped and thought that anyone who could program a VCR was a genius.

The effort to learn new things is too much of a bother for some. The rest of us love the idea.

By: Hinermad

Hinermad — Sun, 09 Aug 2009 14:46:50 +0000

Debuggung is actually two related tasks: finding the bug and fixing the bug. Fixing the bug is usually regarded as being the easier of the two; if one has the knowledge to create a system with a bug, one probably knows how to remove it, or at least replace it with something that works better.

Finding the bug is another issue, and it does require knowledge of the design and underlying technologies. But the process can be taught. “Divide and conquer” works very well, and pretty much describes the method used by everyone except the truly gifted or the divinely lucky. And even the truly gifted usually use that method. They only make it look like they got it right on the first try because their experience and knowledge let them come up with a mental list of potential causes and the relative probabilities of each, then they test the most likely one first. Ask an experienced mechanic why your car won’t start. In a heartbeat he’ll think of a dozen possible reasons, then ask you when was the last time you put gas in the tank. (It’s people like this that encourage Howard’s wankers to try to stare down a problem. They see the battle-scarred veterans do it, but they don’t realize that each scar represents the hard-won experience that makes it possible. We all have to pay our dues one way or another.)

One extension of debuggung I wish more people understood is Root Cause Analysis. Lots of people due to laziness, schedule pressure, or lack of knowledge will fix a symptom and never fix the underlying problem. The unofficial mantra of Root Cause Analysis is “ask ‘why?’ five times.” Each answer leads to the next “why?”, and may even lead to causes (and suggest fixes) outside the system in question. And by answering each “why?” you learn a lot more about the system.

By: Howard Berkey

Howard Berkey — Sun, 09 Aug 2009 02:39:57 +0000

There are a number of methods that can be taught; debugging is not really an art, it’s more of a craft really. You become skilled at it but you do so by following various relatively mechanical techniques.

As an example, the first step in debugging is to *isolate the problem*. The way you typically isolate a problem is via a form of binary search. You can do this in various ways; breakpoints, probes (even printf), etc. This is common across almost ALL domains involving complicated systems, not just software.

A common next step is simply to *reduce the problem* into a reproducible and hopefully simpler case. Again true across many domains.

You really nail the actual meat of the method with points 3 and 4 in your list above, though. The only valid way to really debug is to collect metrics, analyze them, modify the code, and check results. It’s kind of a shorthand for the scientific method. At this point professionals also build new test cases based on the mentioned metrics collection that check this condition so that it can be regressed in the future.

Too often you see some wanker try and stare down a debugging problem as if he can force the bug away by sheer will of thought. It’s a lot easier to behave like a scientist rather than a magician :) This is actually a mark of inexperience and usually plagues mid-level engineers for some reason. I certainly was guilty of it. It’s like you have a little experience under your belt so you feel like you can figure out potentially complicated issues by working through them in your head. Maybe you can, but it is a lot easier combined with the above techniques.