Debugging terminology

The term “bug” has long been part of computing jargon. We have, in fact, been referring to software or computer problems as bugs practically for the entire time that computers have been around. Nowadays, the term has found its way well into the mainstream and it is easy to find mention in regular news coverage.

How did this happen?

The origin of the word in the context of computing is not that clear. No discussion is of course complete without mention of the oft-repeated story of Grace Hopper’s engineering team’s locating of an actual moth in the machine – with said bug still on display in a museum to this day. That was in 1947.

That is not the term’s origin story, though it may make a nice one, as emphatically explained in Etymology of the Computer Bug: History and Folklore. Apparently Thomas Edison was using the term bug to refer to technical difficulties and/or faults in the context of his inventions as early as 1878:

The first step is an intuition, and comes with a burst, then difficulties arise — this thing gives out and [it is] then that “Bugs” — as such little faults and difficulties are called — show themselves and months of intense watching, study and labor are requisite before commercial success — or failure — is certainly reached.

Stalking the Elusive Computer Bug, by Peggy Kidwell examines this in more historical detail. It makes for a fascinating read! More startlingly, Moth in the machine: Debugging the origins of ‘bug’ points out the relationship to old terms for monsters, gremlins. I cannot help but imagine (probably unfairly) people at the very dawn of the information age (superstitiously?) discussing “bugs” happening in (or to?) their programs or machines.

And now here we are. The most valuable and innovative companies in the world would not exist without modern computing technology — and we are without irony still talking about bugs in our machines.

Is that a problem?

When I think of bugs, I mostly think of, well, insects. On the spectrum of life’s problems, they would largely register as annoyances. Thus, this term seems to trivialize the issue — considering some of them (even if they started as mere typos) may well cause very costly damages. In Bugs or Defects?, Watts Humphrey made this argument:

By calling them “bugs,” you tend to minimize a potentially serious problem. When you have finished testing a program, for example, and say that it only has a few bugs left, people tend to think that is probably okay. Suppose, however, you used the term “land mines” to refer to these latent defects. Then, when you have finished testing the program, and say it only has a few land mines left, people might not be so relaxed. The point is that program defects are more like land mines than insects. While they may not all explode, and some of them might be duds, when you come across a few of them, they could be fatal, or at least very damaging.

In comparison to more abstract terms like errors, defects or faults, bugs seem more tangible. In fact, they seem rather like external entities. The inconvenient truth however is that those bugs are largely created by the same people who also create the product.  In On the cruelty of really teaching computing science, Edsger Dijkstra brought this to a point:

We could, for instance, begin with cleaning up our language by no longer calling a bug a bug but by calling it an error. It is much more honest because it squarely puts the blame where it belongs, viz. with the programmer who made the error. The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer’s own creation. The nice thing of this simple change of vocabulary is that it has such a profound effect: while, before, a program with only one bug used to be “almost correct”, afterwards a program with an error is just “wrong” (because in error).

Finally, usage of the term is burdened with ambiguity. Bugs can refer to bad code, incorrect execution or wrong results. In the excellent Why Programs Fail – A Guide to Systematic Debugging, Andreas Zeller elaborates:

This ambiguity of the term bug is unfortunate, as it confuses causes with symptoms: The bug in the code caused a bug in the state, which caused a bug in the execution— and when we saw the bug we tracked the bug, and finally found and fixed the bug.

The language we use is important to how we think about problems and go about solving them. There are at least a few issues with using the term “bug” and we would benefit from finally moving away from it.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s