If I Only Changed the Software, Why Is the Phone on Fire?
Posted on March 11, 2011
by Tommy McGuire
I just returned from a vacation having read If I Only Changed the Software, Why is the Phone on Fire?: Embedded Debugging Methods Revealed, by Lisa Simone. I have to admit that this is not a great book; it did nothing to change the way I think and I don't remember seeing anything that I had not seen (or done) before. However, it is a pretty nice introduction to the subtle skill of debugging.Debugging is a difficult thing to teach. In fact, it seems to me to be more difficult to teach than to learn: I have never seen an attempt to teach debugging succeed on any greater level than a list of tips and rules of thumb. On the other hand, the most successful debuggers, and the most effective debugging efforts, have completely transcended any tips or rules. The person doing the debugging coupled a deep (if not specific) understanding of the system or at least technology in question with the problematic behavior to arrive on the trail of the problem almost mystically.
Of the works that try to present a more thorough approach to debugging than a list of tips, many that come to mind attempt to teach a simplified, corrupted version of the scientific method: hypothesis followed by test; hypothesis, test; hypothesis, test. Unfortunately, without some significant guidance on the hypothesis phase, that method boils down to guess-and-hack, which is horribly inefficient. The whole art of debugging is in determining a likely, or at least useful, hypothesis.
If I Only Changed the Software... does not try to present a grand theory of debugging, and it does have a list of tips, but it does more to teach the feeling of debugging than any other work I've read. Perhaps the fictional, narrative-based style can teach what the process of debugging looks like.
One nice (although someone else may feel otherwise) feature of the book is the use of, well, less than perfect code in examples. Certainly, when I was less experienced than I am now, I would have found the code a ghastly horror and a crime against nature. In fact, I would probably have been right. On the other hand, having seen more code, I now view the examples in the book as pretty typical. Certainly, none of it is procmail.
The big benefit of the code is that it demonstrates a bug may not be the bug. For example, the following is taken (and simplified) from one of the book's examples:
/*The function periodic_timer appears to be called every ten milliseconds. The bug I immediately spotted involves the code labeled with "1000 msec"; it is actually executed every 100 milliseconds. However, that issue is completely unrelated to the bug described in the chapter. Updating the oven-heater-on pulse width ten times more frequently than expected should not have any particular ill effects, certainly nothing involving the actual problem. That is a vital lesson for anyone doing debugging.
Function: Part of ISR. Every 1000 ms the new ovenPW is calculated.
*/
void periodic_timer()
{
/* ------ 10 msec ------ */
... code ...
/* ------ 1000 msec ------ */
ten_msec_ctr++;
if (ten_msec_ctr == 10)
{
...
ovenPW = ...
ten_msec_ctr = 0;
}
}
I would recommend If I Only Changed the Software... to just about any programmer, certainly anyone inexperienced in the task that has occupied much of my career. Although at least some exposure to low-level programming would be good, embedded programming experience is not a requirement. The book may be focused on embedded debugging, but the lessons are applicable to any programming task.
