No Place for Bugs to Hide

—Andy Hunt

04/18/2013
Published in Andy's Blog

We talk about “bugs” in software as if they were caused by some unavoidable, blood-thirsty third-party that invades our pristine code, much as ants might attack a sweet picnic basket or mosquitoes an exposed neck.

But while bugs seems to be both unavoidable and blood-thirsty, they of course aren’t coming from anywhere but our own hands. We make them, and then they sit there, hidden in plain sight, right in front of us. Waiting for just the right moment (the demo in front of the vice-president?) to spring out from hiding and mock our calm expertise.

Do you know why we advocate the practices that we do in modern programming? Sometimes the reasons get lost in the drive to full buzzword-compliance; or perhaps you’re doing a programming practice because everyone else is doing it, or because some author recommended it. So let’s talk about why.

If you can cut down the number of places for bugs to hide, then when you do create a bug, you’ll find out about it right away. Not a month or six from now, once the app has been approved or the startup has launched or whatever. Get rid of the hiding places and you can fix the bugs now, while they remain small (bugs that hide, of course, snack on leftover code and grow stronger and larger with each passing day).

So here are but a handful of popular practices that help eliminate hiding places:

Unit tests

Why do a unit test at all? For only one really compelling reason: to prove that the code you just wrote does what you think it does. The tests pass, and know you know with some certainty what the code is really doing. That still might not be the right thing for it to do, but at least you’ve removed one breeding area for bugs.

End-to-end Tracer Bullet Development

The first iteration of a system should go from end-to-end, even if it’s as simple as “Hello, World!” That is to say, you’ve got all the major parts hooked up as it will be in the final system: from database through browser via some middleware, that sort of thing. No single part has to do much at all, but it needs to be there—to shine a light and remove a dark hole where bugs can hide.

Buddy up to Prevent Bug-Blindness

We are all particularly blind to the bugs we create, but fortunately a second pair of eyes (someone else’s, preferably) can usually spot them when we can’t. So practices such as Pair-Programming, or Code Reviews (be they nice and informal or excruciatingly formal) can really help identify our own blind spots. Have someone else check all your code before you check it in.

Frequent Delivery / Demo

And of course, nothing brings bugs out into the spotlight as effectively as an audience. Bugs just love the spotlight in front of a live audience, it’s a great chance for them to show off. And get caught. So give them the opportunity often: deliver working software every week or two, and demonstrate it to someone who cares. The bugs can’t resist the urge to show off, and then you’ve got them nailed.

You need to know what the rest of your team is working on. You need to know when they’re stuck, or when a subtle change in direction or design starts to gain traction. By the same token, you want your buddies to know when you’re stuck or have come up with a new direction. The classic Stand Up Meeting from Scrum is a great way to do this: it’s a quick meeting, you do not go into problem-solving mode, you simply answer three questions:

What did I accomplish yesterday? That is, what concrete thing works now that didn’t work or exist before? Never answer with an abstract form of “I’m working on xyzzy.” That’s a dark hiding place. Be concrete.
What am I going to accomplish today? What’s your goal to get working today? Same criteria apply as to the first question.
What is in my way? This can be a big one. Do you need help? More resources? An answer from a reluctant source? The list of these blockers is your manager’s TODO list.

There are all sorts of other ways to reduce hiding places for bugs: information radiators, continuous build machines, code-level techniques including refactoring, and many others. None of these techniques will stop you from enbugging in the first place, but they will help you find them and squash them more quickly.

Code can be a dangerous place. Keep it well lit, and do go in there alone ;)

Keep up to date with my low-volume newsletter and don't miss another article or fresh idea:

Your subscription could not be saved. Please try again.

Your subscription has been successful.