Why Do We Call a Software Glitch a ‘Bug’?

“It’s not a bug, it’s a feature.” At one point or another we’ve all heard someone use this phrase or a variation thereof to sarcastically describe some malfunctioning piece of equipment or software. Indeed, the word “bug” has long been ubiquitous in the world of engineering and computer science, with “debugging” – the act of seeking out and correcting errors – being an accepted term of art. But why is this? How did an informal word for an insect become synonymous with a computer error or glitch?

According to the most often-repeated origin story, in 1947 technicians working on the Harvard Mk II or Aiken Relay Calculator – an early computer built by the US Navy – encountered an electrical fault, and upon opening the mechanism discovered that a moth had had flown into the computer and shorted out one of its electrical relays. Thus the first computer bug was quite literally a bug, and the name stuck.

But while this incident does indeed seemed to have occured, it is almost certainly not the origin of the term, as the use of “bug” to mean an error or glitch predates the event by nearly a century.

The first recorded use of “bug” in this context comes from American inventor Thomas Edison, who in a March 3, 1878 letter to Western Union President William Orton wrote: “You were partly correct. I did find a “bug” in my apparatus, but it was not in the telephone proper. It was of the genus “callbellum”. The insect appears to find conditions for its existence in all call apparatus of telephones.”

 The “callbellum” Edison refers to in the letter is not an actual genus of insect but rather an obscure Latin joke, “call” referring to a telephone call and bellum being the latin word for “war” or “combat” – implying that Edison is engaged in a struggle with this particular hardware glitch. In a letter to Theodore Puskas written later that year, Edison more clearly defines his use of the word: “It has been just so in all of my inventions. 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.”

Where Edison himself got the term is not known, though one theory posits that it originated from a common problem plaguing telegraph systems. For almost 40 years since their introduction, electric telegraphs were limited to sending a single message at a time over a single wire. As the popularity of telegraphy rose through the mid-19th Century, this limitation became a serious problem, as the only way to allow more messages to be sent was to install more telegraph wires – an increasingly inelegant and expensive solution. This lead inventors around the world to seek out methods for transmitting multiple signals over a single wire – a practice now known as multiplexing. By the 1870s several inventors had succeeded in perfecting workable multiplex or “acoustic” telegraphs, which generally worked by encoding each individual signal at a particular acoustic frequency. This allowed multiple signals to be sent along a single telegraph wire, with only a receiver tuned to the sending frequency of a particular signal being able to extract that signal from among the others. Among the many inventors to develop multiplex telegraphs were Alexander Graham Bell and Elisha Gray, whose work on sending acoustic frequencies over telegraph wires would eventually lead them to discover the principles that would be used for the telephone.

In any event, while these early multiplex telegraphs worked reasonably well, they had a tendency to generate phantom signals in the form of loud “clicks” that reminded many telegraph operators of the sound of an insect. Thomas Edison himself patented an electronic workaround to this problem in 1873, which he referred to as a “bug catcher” or “bug trap” – suggesting this phenomenon as a likely origin for the term.

Another hypothesis points to the word “bug” being derived from the Middle English bugge, meaning “a frightening thing” or “monster.” This root is also the source of the English words bogeyman, bugaboo, and  bugbear – the latter originally referring to a malevolent spirit or hobgoblin but today used to mean a minor annoyance or pet peeve. Advocates for this hypothesis therefore posit that “bug” in this context was used in much the same manner as “gremlins,” the mythical goblins that WWII aircrews blamed for malfunctions aboard their aircraft.

Whatever the case, Edison’s frequent use of the term in his letters and notebooks lead to it being widely repeated in the press, with a March 11, 1889 article in Pall Mall Gazette reporting: “Mr. Edison…had been up the two previous nights working on fixing ‘a bug’ in his phonograph—an expression for solving a difficulty, and implying that some imaginary insect has secreted itself inside and is causing all the trouble.”

Edison and his so-called “insomnia squad” ’s habit of staying up all night to fix particularly stubborn technical problems was of particular fascination to the press, with Munsey’s Magazine reporting in 1916: “They worked like fiends when they [were] ‘fishing for a bug.’ That means that they are searching for some missing quality, quantity, or combination that will add something toward the perfect whole.”

The term was first formally standardized by engineer Thomas Sloane in his 1892 Standard Electrical Dictionary, which defined a “bug” as: “Any fault or trouble in the connections or working of electric apparatus.”

Three years later Funk and March’s Standard Dictionary of the English Language defined the term for the general public as: “A fault in the working of a quadruplex system or in any electrical apparatus.”

Thus by the early 20th Century the term was well-established in engineering circles, and soon began making its way into everyday usage. One notable early appearance was in a 1931 advertisement for Baffle Ball – the world’s first commercially-successful pinball machine – which proudly proclaimed “No bugs in this game.” Science fiction writer Isaac Asimov further popularized the term in his 1944 short story Catch the Rabbit, writing: “U.S. Robots had to get the bugs out of the multiple robots, and there were plenty of bugs, and there are always at least half a dozen bugs left for the field-testing.”

Despite being in use for over 70 years, it was not until the aforementioned moth incident in 1947 that the term “bug” would become inextricably associated with the field of computer science. The insect in question was discovered lodged in Relay #7 of the Harvard Mark II in the early morning hours of September 9. Later that day the night shift reported the incident to Navy Lieutenant Grace Hopper, a computing pioneer who would later go on to develop FLOW-MATIC, a direct ancestor of COBOL and among the very first high-level programming languages.

In any event, at 3:45 PM Hopper taped the slightly crispy moth into the computer’s logbook with sellotape, gleefully noting beside it: “The first actual case of a bug being found.”

As British cybersecurity expert Graham Cluley notes, Grace Hopper’s whimsical logbook entry clearly indicates that the term “bug” was well-known at the time, but:

“…while it is certain that the Harvard Mark II operators did not coin the term ‘bug’, it has been suggested that the incident contributed to the widespread use and acceptance of the term within the computer software lexicon.”

The historic logbook page, complete with preserved moth, survives to this day in the collection of the Smithsonian Museum of Natural History in Washington, DC, though it is not currently on public display. And in commemoration of the infamous incident, September 9 is celebrated by computer programmers around the world as “Tester’s Day” – reminding everyone of the vital role played by those who tirelessly hunt and slay the various glitches, bugs, gremlins, and ghosts in every machine.

If you liked this article, you might also enjoy our new popular podcast, The BrainFood Show (iTunes, Spotify, Google Play Music, Feed), as well as:

• The Origin of the @ Symbol and the First Email Message
• Who Invented the Internet?
• How the Word “Spam” Came to Mean “Junk Message”
• The Nazis, Hitler, the Internet, and Godwin’s Law
• Can You Really Just Go Online and Order a Wife from Some Other Country?

Bonus Fact

 While we tend to think of software bugs as minor annoyances and inconveniences at worst, depending on what a piece of software is controlling, they can have serious real-life consequences. Among the most notable examples of this is the tragic case of the Therac-25, a computer-controlled cancer therapy machine produced by Atomic Energy of Canada Limited starting in 1982. The unit contained a high-energy linear electron accelerator which could either be aimed directly at the patient or at a retractable metal target, generating an x-ray beam that could reach tumours deeper inside the body. The machine could also be operated in “field light” mode, in which an ordinary light beam was used to line up the electron or x-ray beam on the patient.

While AECL had achieved a perfect safety record with its earlier Therac-6 and Therac-20 machines through the use of mechanical interlocks and other physical safety features, the Therac-25 dispensed with these entirely, its designers relying solely on the machine’s control software to ensure safety. Unfortunately, this software contained two serious software bugs which soon resulted in tragedy. The first of these allowed the electron beam to be set to x-ray mode without the metal x-ray target being in place, while the second allowed the electron beam to be activated while the machine was in field light mode. In both cases, this resulted in patients being bombarded with an electron beam 100x more powerful than intended. The initial effect of this was a powerful sensation of electric shock, which lead one patient, Ray Cox, to leap from the table and run from the treatment room. Between 1985 and 1987 six patients in Canada and the United States received massive radiation overdoses, resulting in severe radiation burns, acute radiation poisoning, and – in the case of three of the patients – death.

A subsequent investigation revealed the truly shocking depths of AECL’s negligence in developing the Therac-25. While the two lethal bugs had been reported during the control software’s development, as the software was directly copied from the earlier Therac-6 and Therac-20 and these machines had perfect safety records, the report and bugs were ultimately ignored.

Of course, the earlier machines relied on mechanical interlocks for safety and their software was written to reflect this, leaving the Therac-25 control software with almost no built-in failsafes and no way of communicating potentially lethal errors to the operator. Even more disturbingly, the software was never submitted for independent review and was not even tested in combination with the Therac-25 hardware until the machines themselves were installed in hospitals. Indeed, throughout the Therac-25’s development cycle little thought appears to have been given to the possibility of software error leading to dangerous malfunctions, with a Failure Modes Analysis conducted in 1983 focusing almost exclusively on potential hardware failures. Software failure is mentioned only once in the report, with the probability of the machine selecting the wrong beam energy given as 10^-11 and the probability of it selecting the wrong mode as 4×10^-9 – with no justification given for either number. This absolute confidence in the software ultimately served to prolong the crisis. Following the first two overdose incidents in 1985, AECL was ordered by the FDA to investigate and submit a solution. Refusing to believe that the software could be to blame, AECL concluded that the issue lay with a microswitch used to control the positioning of the machine turntable, and in 1986 submitted this fix to the FDA. This, of course, did nothing to solve the problem, leading to three further overdoses before the actual cause was finally tracked down.

Once the fault was uncovered, the FDA declared the Therac-25 “defective” and ordered AECL to develop a full suite of corrective modifications. These were all implemented by the summer of 1987, but no sooner was the Therac-25 returned to service, another patient in Yakima, Washington, received a massive overdose, dying of radiation poisoning three months later. This incident was caused by yet another software error – a counter overflow – which caused the updated software to skip a critical safety step and withdraw the x-ray target from the electron beam. In the wake of the six incidents AECL was hit with multiple lawsuits by the families of the victims, all of which were settled out of court. Since then no further accidents have been reported, with the original Therac-25 units continuing to operate for nearly two decades without incident.

The Therac-25 affair has become a seminal case study in safety and systems engineering, dramatically illustrating the dangers of blindly trusting pre-existing software and of not thoroughly testing hardware and software together as a complete system. It also serves as a stark reminder that in our modern, hyper-connected world, the effects of software are not limited to the inside of a computer; sometimes, they can slip out into the physical world – with devastating results.

Expand for References