Don't write bugs

“If you want more effective programmers, you will discover that they should not waste their time debugging, they should not introduce the bugs to start with.” —Edsger Dijkstra, Turing Award Lecture (1972)

I was a High School Junior when I received in the mail the issue of Computer Language magazine that changed the way I program. The feature article, by Robert Ward, was about debugging, and led with the sentence:

Debugging is an important, time-consuming, and necessary part of programming.

I didn’t read the rest of the article because I got stuck on the word “necessary”. Why is that so? Why can’t we just write bug-free programs?

I spent the next two years keeping a log of my bugs, both compile-time errors and run-time errors, and modified my coding to avoid the common ones. I eventually wrote a website called Elements of C Style that captured some of this advice. That site is now unpublished (except for that link) because the advice is too low-level and C-oriented to be useful anymore. Instead I’ve written this new set of maxims. They’re generally higher-level in scope and they use a more modern language (Java) for examples.

My Junior year of college I joined the programming team. During a programming contest, any time spent debugging is time that another team member could be using the computer to type (three members share one computer), so we practiced writing bug-free code. After two years of practicing, and after my previous two years of log-keeping, I was able to write substantial programs (thousands of lines) and run them without compile or run-time errors on the first try. I can’t do that anymore (that was 20 years ago!), but the exercise convinced me that bugs don’t creep into our code by themselves. We put them there, and we can decide to not put them there. Treating bugs as though they were consciously written goes a long way to not writing them.

If you want a single piece of advice to reduce your bug count, it’s this: Re-read your code frequently. After writing a few lines of code (3 to 6 lines, a short block within a function), re-read them. That habit will save you more time than any other simple change you can make.