My code is bug-free!

There is an old joke saying: “To err is human, but for a real ****-up, get a computer.” This chimes with many people’s experience of computers [and embedded systems!], because things do go wrong. Often. The irony is that almost all problems with computer systems, that are encountered on an everyday basis, are rooted in software. Who designs, writes and tests software? Human beings, that is who …

Software developers spend quite a small proportion of their time designing and writing new code. Much more time is spent maintaining/updating existing code and debugging the code they have written. A favorite quote of mine came from my friend Jack Ganssle: “Learn to love your debugger; you are going to spend a lot of time with it.” It was quite a few years ago that he said this, but it is just as true now as it was then.

I have a theory about why code has so many bugs. You might ask where they come from. My answer is that they are caused by modern debuggers! My thinking is as follows. Way back in the dawn of time, programmers would code using a pencil and paper. They would carefully write out their code, taking great care with the syntax. They would then “dry run” it on paper to verify the logic. Only then would they initiate the time-consuming process or entering the code, building and executing it. They might still have bugs, but typically they would be small and/or subtle.

Nowadays, developers type the code straight into the machine, use the compiler to sort out the syntax [which is unsafe as it does not know whether you meant = or ==, for example] and then the debugger to sort out execution time problems – bugs. These bugs include the logical errors that should have been spotted during a verification phase that [typically] no longer takes place. The fact that the debugger is so easily available means that developers rely on it instead of using their brains.

So, how can we improve matters? I am not going to suggest going back to coding on paper [but not reject the idea either!]. I think we need to start with terminology and responsibility.

I generally like to say things in a straightforward way. To me, plain, clear communication is all about getting to the point. As a result, I do not like euphemisms. For example, if someone has died, however sad that may be, just say so. Do not tell me that they have “passed away” or “passed on” or the ridiculous “passed”. The relevance of this attitude here is that a “bug” is just a euphemism for “error”. Or, more specifically, “programmer error.”

On a similar theme, Jack Ganssle [he is back again!] addressed this in a recent article. He suggested that the word “bug” is essentially a way of shirking responsibility. Bugs sound like something that flew in through the window and got into your code when you were looking the other way. They sound like they have an independent existence that is quite separate from the efforts of the developer.

It is time to change! Stop talking about abstract bugs and refer to them as errors. “What are you doing?” “I am fixing some errors that I made in my code.” That sounds better; an engineer taking ownership of the problem. I can imagine some managers being shocked to hear that their developers are making errors and many developers not wanting to admit it. But it is time to get real and come out.

My name is Colin and I am an error-prone programmer …