Page 42 - The Art of Designing Embedded Systems

Disciplined Development 29

students break down and weep as they tried to figure out how to order the
cards splashed across the floor), and then waiting a day or more to see how
the run went. Obviously, with a cycle this long, no one could afford to use
the machine to catch stupid mistakes. We learned to “play computer”
(sadly, a lost art) to deeply examine the code before the machine ever had
a go at it.
How things have changed! Found a bug in your code? No sweat-a
quick edit, compile, and re-download takes no more than a few seconds.
Developers now look like hummingbirds doing a frenzied edit-com-
pile-download dance.
It’s wonderful that advancing technology has freed us from the
dreary days of waiting for our jobs to run. Watching developers work,
though, I see we’ve created an insidious invitation to bypass thinking.
How often have you found a problem in the code, and thought, “Uh,
if I change this, maybe the bug will go away?” To me that’s a sure sign of
disaster. If the change fails to fix the problem, you’re in good shape. The
peril is when a poorly thought-out modification does indeed “cure” the de-
fect. Is it really cured? Or did you just mask it?
Unless you’ve thought things through, any change to the code is an
invitation to disaster.
Our fabulous tools enable this dysfunctional pattern of behavior. To
break the cycle we have to slow down a bit.
EEs traditionally keep engineering notebooks, bound volumes of
numbered pages, ostensibly for patent protection reasons but more often
useful for logging notes, ideas, and fixes. Firmware folks should do no less.
When you run into a problem, stop for a few seconds. Write it down.
Examine your options and list those as well. Log your proposed solution
(see Figure 2-5).
Keeping such a journal helps force us to think things through more
clearly. It’s also a chance to reflect for a moment, and, if possible, come up
with a way to avoid that sort of problem in the future.

One colleague recently fought a tough problem with a wild
pointer. While logging the symptoms and ideas for fixing the code,
he realized that this particular flavor of bug could appear in all sorts
of places in the code. Instead of just plodding on, he set up a logic
analyzer to trigger on the wild writes . . . and found seven other
areas with the same problem, all of which had not as yet exhibited a
symptom. Now that’s what I call a great debug strategy-using ex-
perience to predict problems!