The Rules of Programming

Rule 13. Find the Pebble That Started the Avalanche

If I tell you that coding is really debugging, you’ll probably shake your head ruefully and mutter something along the lines of “Ain’t it the truth, buddy. Ain’t it the truth.”

Well, not really—nobody talks like that. But you’d certainly agree with the premise. When you’re turning an idea into a fully working implementation, you’ll inevitably spend a lot more time in the “getting it to work” phase than in the “typing it in” phase. Barring extreme circumstances—a simple idea and a run of incredible luck, say—you’ll spend more time debugging than coding. This is so obvious it’s rarely even stated.

Here’s the twist.

You know that coding is actually debugging, but how does that affect the way you approach coding projects? You know that coding is actually debugging—so what are you going to do about it?

One obvious answer is to write code with fewer bugs. That’s what the rest of this book is about, so let’s set it aside for now. This Rule is about something different: writing code that’s easy to debug.

The Lifecycle of a Bug

Let’s take a step back and think about what debugging actually is. There are four basic stages in the lifecycle of a bug:

1. The bug is detected—you discover the problem.

2. Next it’s diagnosed—you investigate and uncover what’s causing the errant behavior.

3. Then you fix it, changing your implementation to eliminate the errant behavior.

4. Finally, you test to make sure that the bug has actually been fixed and that ...