Two keys to debugging

“What do you know?”

That question was asked constantly in my elementary physics class.  It was a flunk-out class (a class designed to thin the herd at my engineering school.)  The thing was, the professor had a pattern he wanted you to follow when solving problems in his class.  First, draw a diagram.  Second, write out the appropriate starting equation.  To do the second step, you needed to know what you know.  If you are solving for time and have velocity, you’ll need to also know distance.  Sometimes you had distance, sometimes you had to calculate distance.  But you always had to know what you had, and what you needed before you could solve any physics problem.

Years later, I find that one question “What do you know” as one of 2 key elements in troubleshooting.  The other key element is “Play the percentages.”

The phenomenal, albeit fictional, detective Sherlock Holmes once said “When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.” What I love about Sherlock Holmes is how much he knows of varying subjects.   He always knew about soil types, tobacco, habits of longshoremen etc.

In a lot of ways, developers need to have the same abilities.  Sure, we don’t normally don’t need to know about various tobaccos. But we do need to know about when a database trigger runs, or what the normal authentication process is for your site.  Asking questions and taking note of what you know will go a long way to solving a problem.

When you’re chasing down bugs, you need to examine what’s most likely.  Newest changes are the riskiest.  Followed by code that is seldom called.  Followed by mature, frequently hit code.

Debugging, then, becomes much less of a mystery, and much more a quest for knowledge.  Figure out what you know, and start with the areas that are the most likely to have broken.