Good Debugging is Like Magic

I was prompted to write this by a conversation with a friend I had about debugging in general.

These are two stories from my early days as a programmer. They both illustrate the point that good debugging is like a Magic Trick. It’s really amazing until you explain how it was done.

Story 1:

I was working at my first programming job at a bank in Albany NY. I came in one day and the other 3 programmers were all working on trying to solve a crash from the night before. This is in the days of memory dumps and not much else information was available. I had already been there a couple of months, and the other programmers actively disliked my showing them up, debugging-wise, that they didn’t want me to look at problems like this, until they had the chance to solve it themselves first.

I got enough information about the problem to glean a possible cause, and asked them for the Level-2 manual so that I could look up something. They asked me what I was going to look up and then told me it wasn’t that because they had just looked that up themselves. Sure enough though, that was the problem and I showed them why.

Dejected at my solving the problem for them, Glen said, “Hey Phil, give Joe the “Journal Bug”. Phil said, “He’s only been here 2 months, he doesn’t know enough about the journal stuff to solve it. It’s been over 18 months now, and no one’s ever solved it.” Glen said “Give it to him anyway” (and something to the effect of, “maybe that will shut him up”.

Phil brough over two listings, laid them side by side…and said, “The bug is in this area of the code. These two routines should produce the same results but something is off and they don’t match.” I started to look at the two listings as Phil started walking away. He hadn’t made it back to his own desk when I said – “I think I found it.” — Glen starts saying – “No fucking way, no fucking way.” (A few times). Phil walked back to my desk, and I pointed out the bug…and to his credit Phil said – “Yep, that’s it. I don’t know how many times I’ve looked at that and never saw it.”

Impressive right??? But like a Magician explaining the trick — once I do, I don’t think you’ll be as impressed.

Here’s the gist of the code…

If (flag1 == 1) {
DoSomeStuff();
…
…
…
flag1 = 0;
}

if (flag2 ==1 ) {
DoSomeOtherStuff();
…
…
…
flag2 = 0;
}

….etc..etc…(all the way to flag14 if I remember correctly).

However….this is what flag5 looked like….

If (flag5 == 1) {
DoSomeMoreStuff();
…
…
…
flag6 = 0:
}

Do you see it? — I did.
Had no idea what the routines were doing, but I knew that “flag6=0” was wrong and should have been “flag5 = 0”.

To me, that’s not impressive. What’s impressive is so many other people not seeing it.

Story 2:

To keep it short – I saw code that was doing a sequential search of a 300+ entry table on every record looking to slot a store record of an employee who worked at a restaurant that week. This system did not have a notion of “totals” and by the end of the year passed 52 records per employee. Programs that ran 30 minutes at the beginning of the year, took 5 & 6 hours by the end, and there were many different programs using this technique.

My first thought was that they should be doing a binary search because the table was indeed ordered, but before I tried that out, I had a brilliant idea that cut run times by about 80%. Sounds impressive, doesn’t it?

But here’s the Magic explanation again.

I noticed that most employees work at the same store week after week although there were exceptions…so…
instead of starting the search of the 300+ table, I wrote one line of code that basically said:

“If you’re already at the correct spot in the table, don’t search for it, you’re already there.”

Boom — 80% speed up.

So Magical.

____________________________

I’ll leave you with this thought.

99% of all computer problems are basically like that old joke that goes like this:
Man says: “Doctor, Doctor – It hurts when I do this” (Hold arm way back extended above head).
Dr. replies: “Then don’t do that.”