The Debugging Golden Rule

Don't question others until you've questioned yourself.

Developers, especially new developers, often forget this when debugging. We jump into the debugger. We add tracing statements. We review the commit log.

Such actions can be misguided. Before debugging the code we must follow a moral code. Debugging needs a Golden Rule. A rule to remind developers of a few important facts of debugging.

99% of the time it's you

I had an excellent TA for my introductory Computer Science course. He gave great advice for improving your craft. Some of which became the foundations for routines of a good developer.

In one of our more difficult labs he expressed his frustration with the class:

Listen up! Stop asking me, "What's wrong with gcc?" gcc has been widely used for over three decades. You have been programming for half a semester. gcc is not broken!

I remember his words anytime I start questioning others. A far majority of the time, the bug is in my code.

Avoid tunnel vision

Debugging is the art of asking the right questions. If you start by questioning others, you will likely waste your time asking the wrong questions.

We've all done it. A recent upgrade revealed a bug in the code. Now you have a bug in your brain: it's the upgrade.

Of course you should question the upgrade. But question other changes too.

You still have to fix it

Let’s say you prove the language has a bug, Internet Explorer behaves differently, or the developer before you broke the build. What then?

Well, you still have to fix it. Even when it is not you, you still must develop the fix. No point in focusing on blame.

Following the Debugging Golden Rule keeps developers grounded, focused, and part of the solution. Remember it the next time you find a bug in the code.

Comments

[Derek Hopper]

I definitely agree with you here: "99% of the time it's you."

Thinking back through years, this rings true. There have been a couple of occasions where there's been a bug in a Ruby gem or even an issue with Rails itself. However, the vast majority of the time it's either misuse of the gem or misunderstanding of a Rails API.

Like you said, searching for blame is a waste of time. It doesn't get you any closer to solving the problem. This is even more important when trying to ship a hot fix. Every minute you spend searching for blame is another minute of production being unstable.

I think it's ok to come back later, after you've fixed an issue, and figure out what went wrong. Maybe there's a process you can improve or some testing you can build. If we keep our focus on learning and getting better, there should be no time for the blame game.

[Jason McCreary]

For sure. Such things should be mentioned in a retro or standup after the fix. Especially if the fix resulted in any kind of outage or is a chance for the whole team to learn a different practice.

[Vikram Jaswal]

Nice post. Mindset can have a great impact on a developers productivity.

Side note :

"But question question other changes too."

^ The word question is repeated here, you might want to fix that.

[Jason McCreary]

Thanks. I have corrected the typo.

[M.]

I agree but in my case it is well under 99%.

As developers tend to blame the other developer, I am often in the latter position. I'ld agree that it is not me initiating the bug report, but the argument is often that my code upgrade or my implementation is not correct.

So I am prepared to debug the code that I did not write and I only file a report back once Ihave the proof where the bug is located. That is in my experience the fastes way to go forward.

Debugging code that you do not necessarily have access to is another ball game, but it is an interesting skill set.

Amongst the bugs I have discovered there are:

• a Pentium bug where a left shift of a register of 32 bits did not work: the register was left untouched, while shifting it 33 bits did return 0 and a 31 bit shift was also correct. I never reported it. My C program worked in one compiler but not in the other : the one where it worked used a 16 bit register model.
• a GCC bug where the "volatile" keyword was(/is) not entirely respected. The “volatile int” that I did some operations on was optimized out. I noticed this during checking compiler performances, so as I am aware of it I know what to avoid. It was a long time ago and I never reported it.
• a bug in the Microsoft .NET mailing functions with regards to security. I found the source code for that bit, confirmed the bug and made a report to Microsoft. After a while Microsoft indicated that they started looking into it, and another while later they indicated that they confirmed the bug but that they were not going to fix it. In the mean time I had worked around it as cleanly as possible based on the knowledge of the inner workings of .NET. I think that was in 2014.

So bugs in renowned systems do exist. While you have to consider your own Work first as the source of bugs, you do need to pay attention to any deviation from the expected behaviour and if it is a third party, build a "simple" test case that it is the third party. That test case can then serve for your bug report if needed.

[Dar Brett]

I think 99% is an exaggeration for a lot of industries.

Recently I've been working in NodeJS - where it's incredibly likely that someone on the team has pulled in some dependency that someone hacked together without testing. So that's the first place I look.

Previously I've worked in the Enterprise .Net/Java space where most of the time any obscure bug is in some vendor software - for example in one form engine I remember where in several releases the underlying call to .Net's SMTP 'SendMail()' method was accidentally removed. If the license agreement hadn't forbidden decompilation I'd have been able to prove it to them in hours instead of weeks.

For higher quality open source software, such as GCC and the Linux Kernel 99% might not be far off. I for one have never found a bug in a mature open source project.