Debugging Rule 1: It’s your fault

I recently added Debug It! to my stack of books to read, and I’m looking forward to digging in to it. In the mean time here’s a little debugging advice from my own experience:

It’s your fault.

I have GMail set up to SMS me when I break the build. Nearly every time I get the dreaded notification, I go through the same defensive routine. “But the tests passed locally!” I protest. “I wasn’t working on anything that would have affected that!” I explain. “There’s no way that could POSSIBLY be related” I whine. “That shouldn’t even be possible!” I complain. “It’s not my fault!”

Nine times out of ten, though, after grudgingly debugging the issue I discover that yes, in fact, my changes were the culprit. Some unforseen side-effect of my changes caused the full-stack tests to fail. It’s usually an easy fix, albeit not always an obvious one.

The lesson here? Software is complex, and my brain is small. I often don’t even remember all the changes that went into a particular feature commit; there’s no way I can predict every tertiary effect those changes will have. Nine times out of ten I’d save myself some time and my team some grief if I just assumed it was my fault and got to work.

This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.

Related posts:

1. The three line rule