Parks' Laws of Debugging

Over my life as a software developer, I've collected several rules of thumb that guide me in my work, but these two “laws” have been remarkably useful. Like a lot of so-called laws in software development, they're just heuristics, but they have held up so many times that I assume they're true until proven otherwise.

These laws weren't formulated overnight; instead, they are reminders of hard lessons learned in the trenches.

Parks' First Law of Debugging

For any given defect report, there is always more than one bug in play. Fixing the first bug you find will not automatically resolve the defect.

When a customer reports a serious bug in your software and is chasing your team for a fix, you're inclined to want to fix it as quickly as possible. As soon as you find The Bug and apply a fix, you may experience a sort of tunnel vision, where you convince yourself that the bug really is fixed and it's time to ship the fix. This law reminds you that software is complex, and it can behave in unexpected ways. In fact, fixing the bug may well introduce yet another bug!

Parks' Second Law of Debugging

If you cannot reproduce a bug in a controlled environment, then for the purposes of debugging the bug does not exist.

This one sounds like I'm pretending not to see bugs, but that's really not the case. What it means is that until you can actually reproduce a bug reliably, then you're stabbing in the dark, and you're at risk of running afoul of the first law.

A Deeper Explanation of the Second Law

Someone on LinkedIn made the comment that the second law ignores situations like race conditions, where the bug might be very difficult to reproduce. It's actually situations like that which motivated me to come up with this “law.”

Suppose a QA engineer tells me that something really weird just happened during testing, but it's not always reproducible. I believe the engineer, but I am in a quandary: I can keep my team working on fixing bugs which can be reproduced, or I can pull someone off and have them chase this elusive bug. At that point, it's a question of severity. Does the bug cause a button's background to be the wrong shade of mauve, or does it move a decimal point in a financial calculation? If it's the former, it goes to the bottom of the pile. If it's the latter, then as long as all the other bugs are lower in priority and severity, I assign someone to assist the QA engineer in getting a repro. However, I have to make it clear that this is NOT debugging. It's getting a solid, stable repro. Only after QA and development are satisfied with the repro can we move on to debugging. Otherwise, the QA engineer and the dev might “find” the bug by making it happen one time, “fix” the bug, and by so doing run afoul of the first law.

Note: This article also appeared as a post on LinkedIn.