The latest issue of The Embedded Muse contains the following quote regarding the use of the term “bug” by software developers:
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 is a disguise 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.” – Edsger W. Dijkstra.
After reading this statement I began to think about how I use the word “bug” myself, and also how this term has been used and perceived by other software engineers that I have worked with.
My conclusion is that I would tend to agree with Dijkstra in that this jovial little word often provides a handy way for programmers to deflect blame away from themselves for what are, in reality, mistakes. Perhaps though this is not always such a bad thing.
When working closely with others, keeping things civilised should be a top priority. I’m not sure that scrutinising the “errors” created by colleagues is helpful in this situation, and maybe apportioning some of the blame instead to “the bugs” is a perfect way to keep things light-hearted.
The following message was written in my leaving card by a fellow software engineer when I moved on to a new company, and I think it demonstrates nicely how this small word can play an effective part in building camaraderie within a team.
It is important to note however that these imaginary little mites cannot be made scapegoats for us. We must take responsibility for our own mistakes and ensure that we learn from them.
So in this spirit of self-analysis, I have tried to come up with the top three sources of bugs in the projects that I have worked on, together with the relative heuristics that could be applied to overcome them.
1. Increased code size and complexity
Large, unwieldy and complex pieces of source code make it difficult to spot both your own mistakes and the mistakes produced by others.
Heuristic: Build systems using software components that are as small and simple as possible.
2. Poor understanding of the hardware and software environment
A poor understanding of the programming language, operating system or hardware platform used on a project can lead to subtle errors that may not become immediately apparent. This can lead to strange and erratic behaviour occurring during longer term use.
Heuristic: Seek to fully understand the hardware and software environment. Document any assumptions and have them checked by someone who has a fuller understanding of the system.
3. Hacked code
Changes made to code during a frantic debugging session can easily be forgotten about and may lead to problems if they make their way into production code.
Heuristic: Carry out debugging using a dedicated copy of the source code. Only copy fixes into the production code once they are proven.
Of course there are many other sources of bugs, but these three made the top of my personal list. It would be great to read about your own top sources and their related heuristics in the comments section below.
Whatever the project you’re currently working on: Good luck with it, and watch out for bugs!
DW.