Gerald M. Weinberg
The author comments:
Over the years, I’ve tried to show managers and developers how much serious damage mistakes can cause, but seriousness doesn’t seem to carry much weight with software folks. So, instead, I’ve decided to offer them a lighter view of the subject of errors – starting with the humorous term, “bug.” To paraphrase Oscar Wilde, “Software is too important to be taken seriously.”
Overview
A few years ago, it wasn’t considered in good taste to speak of errors in computer systems, but fashions change. Today, articles and books on software errors are outnumbered only by those on sex, cooking and astrology.
But fashion still rules. Everybody talks about debugging &endash; how to remove errors &endash; but it’s still in questionable taste to speak of how the bugs get there in the first place.
In many ways, the word “debugging” has injured our profession. “Bug” sounds like something that crawled in under the woodwork.
Misled by this terminology, people have shied away from the concept of software errors as things people do, and which, therefore, people might learn not to do.
In this article, therefore, I’d like to shift the focus from debugging &endash; the removal of bugs &endash; to various forms of “bugging” &endash; putting them into the software to begin with. For ease of reference, I’ll simply list the various types of bugging alphabetically.
The Abecedarian
ABC-bugging is creating bugs by “going by the book,” writing code according to some rigid methodology without thinking. The developer who inserts ABC-bugs always has the built-in alibi, “I was just following the process.”
Be-bugging is the intentional placing of bugs in software for purposes of measuring the effectiveness of debugging efforts. By counting the percentage of intentional bugs that were found in testing, we get an estimate of the number of unintentional bugs that might still be remaining. Hopefully, we remember to remove all the be-bugs when we’re finished with our measurements.
C-bugging is a relatively new category of bugging behavior, seen only since some managers have raised fee-bugging (see below) to a high art available not just to contract programmers. C-bugging has nothing (in particular) to do with coding in C – the C refers to “c-note,” the popular slang for a hundred-dollar bill. C-bugging occurs when these managers declare a “bug fest,” where developers are brought on weekends for an all-out festival of bug removal (see re-bugging) and paid cash bonuses for each bug found. One particularly good fest-bugger was heard to say upon entering a bug fest, “Well, here comes my new Camaro” (another possible meaning of C).
De-bugging is a mythical process by which all bugs are supposedly removed from a piece of code. No living human has ever seen this process performed. When people say they are “debugging,” they clearly must be doing something else, something that involves putting more bugs in. This is especially true when they say they are “writing debugging code.” Note on pronunciation: When in Chicago, be sure to distinguish between debugging and the-bugging, which are indistinguishable to the untrained ear. When in New York City, ask the would-be debugger if this is similar to the process by which roaches are debugged from apartment buildings.
E-bugging is the process of quickly placing bugs in perfectly acceptable code in order to move it into a web environment. E-bugging most frequently shows itself in human interface bugs, because the developer and the developer’s manager believes that Internet apps are allowed to forget everything that has previously been learned about human interfaces. E-bugs of various kinds are highly likely to reach users – because managers believe that Internet apps don’t really need to be tested, either.
Fee-bugging is the insertion of bugs by experts you have paid high fees to work on your system. Contract programmers are very skilled at fee-bugging, especially if they’re treated like day laborers on a worm farm. Want an even more effective way to get them to create more fee-bugs? Pay them overtime for removing the fee-bugs they inserted in the first place – and be sure to call them heroes.
Fiddle-dee-dee-bugging is a process that starts when the programmer thinks, “Hmmm, this seems to be finished, but if I could just fiddle with it a bit, I could save a few microseconds, or make it do this nifty trick.”
Gee-bugging is grafting of bugs into a program as a part of a piece of “gee-whiz” coding &endash; fancy frills that are there to impress the maintenance programmers rather than meet the specifications.
He-bugging is, of course, the penetration of code by bugs created by macho programmers using risky coding techniques – the kind only real men would dare to use.
Irony-bugging is the creation of bugs while doing exactly what the author has been advising others not to do. [Thanks to Graham Wideman for pointing out an example of this in this very essay.]
Knee-bugging is thrusting bugs into a program when you’re in too much of a hurry to bend your knee and sit down to think about what you’re doing. We had a motto &endash; “Never debug standing up.” We could well extend that motto to bugging: “Never bug standing up.”
Me-bugging may involve numerous forms of bug installation, for it refers to the method by which they are protected from assault. The programmer regards any attempt to question the correctness of the code as an assault on his or her value as a human being. Those who practice “egoless programming” or “extreme programming” are seldom guilty of me-bugging.
Me-too-bugging appears when management is pushing for “reuse” of code, and the code being reused isn’t really reusable. Instead of saving money, this kind of reuse of bugs pushes the apparent expense from coding into testing.
Pea-bugging can be understood by reference to the story of The Princess and the Pea. The Princess showed her true breeding by being able to feel a pea through a hundred mattresses, illustrating that no bug is too small to be noticed by computers or other royalty. The pea-bugger, however, pops in bugs with the thought “Oh, nobody will ever notice such a tiny glitch,” and the testers confirm they are not the blue bloods of software by confirming this opinion. Pea-bugs are thus left to the true princes and princesses – the customers.
Pee-bugging is the rushing in of bugs when the programmer is impatient to attend to other matters, not necessarily the call of nature. The pee-bugger is the one who is always heard to contribute: “Let’s just get this part coded up so we can get onto more important matters. We have to get them in fast so we’ll have enough time during testing to get them out.”
Plea-bugging is the legalistic method of forcing bugs into software. The plea-bugger can argue anyone out of negative feeling for a piece of code, and is especially dangerous when walking through code, leading the review team around by its collective nose.
Pre-bugging is the art of insinuating bugs into programs before any code is written, as in the specification or design stages. We often hear the pre-bugger saying: “Oh, that’s clear enough for the coders. Any moron could understand what we mean.”
Re-bugging is the practice of re-introducing bugs which were already removed, or failing to remove bugs that were found and supposedly removed. Re-bugging is especially prevalent when working alone on code with quick feedback. Some programmers have been known to collapse from malnutrition when caught in an endless loop of debugging and re-bugging a related pair of bugs – too trapped even to wash down a Snickers with a Jolt.
Sea-bugging is named for the state of mind in which it is done &endash; “all at sea.” The typical sea-bug splashes in when everyone is making waves and shouting: “We’ve got to do something!” That something is invariably a sea-bug &endash; unless it’s two sea-bugs.
See-bugging is the implantation of bugs that “everyone can see” are correct. See-bugging is done in a state of mass hypnosis, often when too many susceptible minds are pooled on the same team or project that’s rushing to meet an unrealistic deadline. This unhealthy state prevails when management values harmony over quality, thus eliminating anyone who might make waves. Of course, too many wave-makers leads to sea-bugging, so programming teams have to be constituted as a compromise between harmony and healthy discord.
S/he-bugging is done all the time, though nobody likes to talk about it. S/he-bugs have a way of infusing your code when your mind is on sex, or similarly distracting topics. Because sex is a topic unique unto itself, all s/he bugs originate by what might be referred to as sexual reproduction. That’s why this is such a populous class of bugs.
Tea-bugging is the introduction of bugs when problems are solved during tea or coffee break conversations and then not checked before passing directly into the code base.
The-bugging (pronounced thee-bugging) is crowding multiple bugs into a program under the “one-program-one-bug” fallacy. The addicted the-bugger can invariably be heard ejaculating: “I’ve just found the bug in my program.”
Wait-and-see-bugging arises when a coder knowingly creates a mess of code that undoubtedly contains multiple bugs but is so confused that s/he decides just to pass the code along the chain and wait-and-see what testing turns up.
We-bugging is the ordination of bugs by majority rule. When somebody doubts the efficacy of a piece of code, as in a review, the majority votes down this disturbing element, for how can three out of five programmers be wrong? Thus are born we-bugs.
Whee-bugging is a symptom of boredom, and frequently arises when effective bug-prevention schemes have become well established. Programmers reminisce about “the good old days” when programmers proved their machismo by writing code in which nobody could find bugs. One thing leads to another, and eventually someone says: “Let’s do something exciting in this code &endash; wheeeeeee!”
Ye-bugging is a mysterious process by which bugs appear in code touched by too many hands. Nobody knows much about ye-bugging because every time you ask how such a bug got into the code, every programmer claims somebody else did it.
Z-bugging is the programmer’s abbreviation for Zap-bugging. The Zap bugger is in such a hurry that it’s unthinkable to use three letters when one will do. Similarly, it’s unthinkable to submit to any time-wasting controls on changes to working code, so the Z-buggers ram bugs into the operating system with a special program called ZAP (or SUPERZAP, if they want to Z-bug the operating system). Z-bugging makes a bookend pair with ABC-bugging – the one from irresponsibly following no rules, the other from slavish conformity to all rules. Although they seem opposites, they actually amount to the same thing – the suspension of thought in order to create the maximum number of bugs.