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 …

Want to stay up to date on news from Siemens Digital Industries Software? Click here to choose content that's right for you


8 thoughts about “My code is bug-free!
  • I like being straight-forward Colin, good point.

    I have many people try to defend to me that they have high quality code, that they hire top-of-the-shelf engineers. My answer is always the same: Congratulations! Want to bet I can find a bug in your code in less than a day using static analysis?

    Nobody has taken me up on it yet, sadly.

    In the future, I shall use ‘error’, instead of ‘bug’.

    Mark Hermeling

  • The first documented computer ‘bug’ was a moth stuck in relay contacts, found by Grace Hopper in 1947. Note that this was a hardware problem causing software malfunction.

    As Colin says, most ‘bugs’ are really programmer errors – either in coding implementation, of in the design of the problem being solved. The more we rush to churn out megabytes of code, the more likely we are to leave open systemic ‘barn doors’.

    Compiler syntax checks and debuggers are only preliminary checks. Proper software engineering (rather than just coding drones) is to properly define inputs, outputs and functionality and data flows. Test harnesses, unit testing and carefully considered corner cases are part of ensuring our code works as intended in all circumstances. The exceptions are more likely to bite you than simple failures of the primary intended function.

  • So glad you all decided that you are human and make coding errors. There is an easy solution-Functional Testing and Automated Regression testing. Certainly you’ve heard of this-this capability has been around for about 20 years-I’m sure as long as you’ve been coding. And you can also audit from the code back to the requirement itself-just in case. How many times have you said “Oh, is that what you meant!” And, to make it even more real for you-lean to the left and start to QA your code before it gets turned over to your QA testing team. The cleaner the code the fewer times you ever have to touch it again!

  • Working environment for sure influences the way of thinking. Surprisingly, it is also true on the lower level, like the editor background color or paper printout, or editor vs debugger layout. We are not thinking in that abstract way, as we would wish, we do. I have learned to see the code in a variety of environments, to understand it better. Another example: peer review – I find my errors easier, talking to my peer.

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at