Where Does the Word "Bug" Come From? From a Moth's Story to Billion-Dollar Mistakes

It's one of the words a programmer uses most: bug. Literally, it means "insect." But no programmer is talking about insects — what's meant is a fault in the code.

So why "insect"? Was it really because of a moth stuck inside a computer? Or is that a story that has turned into legend through endless retelling?

The answer sits between the two — and it's far more interesting than you'd expect.

1. The Origin of the Word: Before the Insect, There Was a Bogeyman

The oldest meaning of the English word bug was not "insect."

In Middle English, "bugge" meant "scarecrow, specter, hobgoblin." It was probably related to the Welsh bwg (ghost, scarecrow). The words bugbear ("something that frightens you for no good reason") and bogeyman still alive in English today come from this root.

So bug originally carried the sense of "an invisible, inexplicable thing that torments you." The insect meaning came later — probably by association with "a small creature that sneaks in and makes a nuisance of itself."

This is an important detail for the story that follows: when engineers called a fault a "bug," they were really saying "the thing hiding somewhere in there that I can't see and that's ruining my day." Less an insect metaphor than a bogeyman metaphor.

2. Thomas Edison, 1878: "Bug" Enters the Language of Engineering

Contrary to popular belief, computer people were not the first to use "bug" to mean a technical fault. The trail of that meaning leads back to the 1870s, and the name we find there is Thomas Edison.

In an 1878 letter describing the process of invention, Edison wrote (in essence): an idea appears, then the difficulties show up — this thing gives out, that thing won't work — and it is then that the little faults and difficulties we call "Bugs" make themselves known. For Edison, whether an invention reached "commercial success or failure" depended on whether those bugs could be cleared out.

Edison didn't use the word once and drop it; it recurs across his notebooks and correspondence. In 1888, telegraph expert William Maver, discussing a known tendency to malfunction in the quadruplex telegraph system, wrote that it was called the "bug" — and that Edison was the one who first called it that.

The telegraphers' "bug"

By the end of the 19th century the term was firmly embedded in the telegraph world. So much so that the semi-automatic telegraph keys used for sending fast Morse code were called "bug keys" — Vibroplex-brand keys still carry an insect logo to this day.

In other words, by the 1940s "bug" was already established engineering jargon. That completely changes the meaning of the famous story we're about to tell.

3. September 9, 1947: The Famous Moth

Here is the most-retold story in the history of technology.

Place: Harvard University, Computation Laboratory.

Machine: The Harvard Mark II Aiken Relay Calculator — an enormous electromechanical computer built on relays.

Date: September 9, 1947.

The machine was producing faulty results. The team went hunting for the fault and found a moth trapped in Relay #70 on Panel F. They removed it with tweezers, taped it into the laboratory logbook, and wrote beside it:

"First actual case of bug being found."

That logbook page — moth still taped to it — is today in the collection of the Smithsonian National Museum of American History.

The legendary part of the story — and the reality

The event is usually told like this: "The first computer bug was a real insect, and Grace Hopper found it. That's where the word 'bug' comes from."

There are three problems with that:

1. The word already existed. We saw it above — Edison was using it in 1878. The note itself gives the game away: "first actual case". That phrasing is only funny if the team was already using "bug" metaphorically. The note isn't announcing a discovery; it's a joke: "We've been saying 'bug' for years — this time it really was one!"

2. Grace Hopper probably wasn't the person who found the moth. Hopper was on the Mark II team at the time and retold the story with great delight for years — which is why the event became attached to her name. But the handwriting in the logbook isn't hers, and there's no firm record that she was in the lab at that moment. Hopper is the narrator of the legend, not its hero.

3. It wasn't "first." Insect-caused failures were a known problem in relay machines; this is the most famous documented instance — not the earliest one.

Does that make the story worthless? Absolutely not. That moth gave an abstract engineering term a physical body. If you want to explain why a word has refused to die for 80 years, that's your answer: people forget definitions, but they don't forget stories.

4. Where Does "Debug" Come From?

The prefix de- in English means "to remove, to strip away" (de-ice, de-frost). Debug = "to remove the bugs."

What's interesting is that "debugging" also predates computers: there are records of the term being used in 1940s aviation for clearing faults out of aircraft engines. Its widespread use in a computing context settled in during the 1950s.

In Turkish, the equivalent is hata ayıklama — literally "fault extraction," translated by meaning rather than by image. In everyday speech, Turkish developers mostly just use the English terms ("bug," "debug etmek"), while formal documentation prefers hata, yazılım hatası, hata ayıklama.

5. Terminology: Bug, Error, Defect, and Failure Are Not the Same Thing

In casual conversation we call everything a "bug." But in the software engineering literature (ISTQB and IEEE standards) these are distinct layers:

• Error / Mistake — The wrong thing a human did (The developer writes `<=` instead of `<`)

• Defect / Fault / Bug — That mistake as embedded in the code (The loop runs one iteration too many)

• Failure — The defect becoming visible at runtime (The app crashes at the end of the list)

Why does it matter? Because not every defect becomes a failure. A bug can sit in code for years and only detonate when one very specific input arrives. This is why Edsger Dijkstra's famous line still holds:

"Testing shows the presence, not the absence of bugs."

And one more distinction: a bug is not a missing feature. If the product behaves as specified but you don't like it, that's not a bug — it's a feature request. Teams that can't make this distinction turn their issue trackers into wish boxes.

6. Types of Bugs: The Technical Taxonomy

6.1. The classic categories

• Syntax error: The code doesn't even compile. The most harmless kind — because the compiler tells you immediately.

• Logic error: The code runs, but produces the wrong result. The most insidious kind.

• Runtime error: Division by zero, null reference, file not found.

• Off-by-one error: The loop runs one time too many or too few. The most classic bug in software. ("There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.")

• Race condition: Two threads touch the same resource at the same time; the result depends on ordering. Reproducing it is hell.

• Memory leak: Allocated memory is never released; the application bloats over hours.

• Overflow: A number exceeds the limits of its data type and wraps around.

• Regression: Something that used to work breaks after a new change.

• Vulnerability: An exploitable bug. Every vulnerability is a bug, but not every bug is a vulnerability.

6.2. The playful names borrowed from physicists

Programmers have given certain bug types nicknames drawn from physics:

• Heisenbug: A bug that vanishes when you try to study it. You attach a debugger and the fault disappears; you detach and it comes back. Named after Heisenberg's uncertainty principle and the observer effect. (Usually caused by differences in timing, memory layout, or optimization.)

• Bohrbug: The opposite of a Heisenbug — a "good, solid" bug. It reproduces the same way every time under the same conditions. A nod to Bohr's predictable atomic model. This is a developer's favorite kind of bug, because a reproducible bug is a solved bug.

• Mandelbug: A bug whose causes are so complex and tangled that its behavior looks chaotic, even non-deterministic. A reference to Mandelbrot's fractals. It looks like a Heisenbug but is really an extremely complicated Bohrbug.

• Schrödinbug: A bug that materializes the moment someone reads the code and says "how has this ever worked? It shouldn't." Until that instant it runs fine; the moment it's noticed, it breaks for everyone. A nod to Schrödinger's cat.

• Hindenbug: A bug with catastrophic consequences. It wipes the database, takes down the server. Named after the Hindenburg disaster.

These names look like jokes, but they serve a real purpose: classifying a bug correctly determines how you hunt it. You can't chase a Heisenbug with a debugger — that requires logging and timing analysis. A Bohrbug, on the other hand, you can step through directly.

7. Bugs That Made History

Most bugs are merely annoying. A few have entered human history.

Mariner 1 (1962) — A single missing overbar

NASA's Venus probe veered off course shortly after launch and had to be destroyed. The cause cited was a missing overbar symbol in a handwritten transcription of the guidance equations. Arthur C. Clarke called it "the most expensive hyphen in history."

Therac-25 (1985–1987) — The case where bugs killed

This radiotherapy machine, used in cancer treatment, delivered massive radiation overdoses to at least six patients; several died. The cause was a race condition: when the operator entered commands quickly enough, the software skipped a safety interlock. In earlier models a hardware interlock had prevented this failure; on the Therac-25 that hardware was removed and safety was left entirely to software.

The case is taught in software engineering ethics courses worldwide. The lesson: "the software will handle it" is not a sufficient reason to remove a layer of physical safety.

Pentium FDIV (1994) — The processor that couldn't divide

Intel's Pentium processor returned incorrect results for certain floating-point divisions. The flaw was spotted by a mathematics professor. Intel first downplayed the problem, then — as public pressure mounted — was forced into a recall costing roughly $475 million.

Ariane 5, Flight 501 (1996) — A copy-paste catastrophe

The European Space Agency's new rocket disintegrated 37 seconds after launch. The cause: inertial reference software carried over unchanged from Ariane 4. Ariane 5 climbed far faster; a horizontal velocity value overflowed while being converted from a 64-bit float to a 16-bit integer. Worse, because the backup unit ran the identical software, the backup failed at the same instant. Loss: roughly $500 million.

The lesson: redundancy only protects you against a different failure. Running the same software twice is not redundancy.

Mars Climate Orbiter (1999) — Unit confusion

The orbiter broke up in the Martian atmosphere. The cause: the ground control software expressed thrust in pound-seconds (imperial) while the onboard software interpreted it in newton-seconds (metric). Total loss: over $320 million.

Y2K (2000) — A non-disaster, or a disaster averted?

The fear that legacy systems storing years as two digits would read 2000 as 1900. Hundreds of billions of dollars in remediation work was carried out worldwide, and on January 1, 2000, nothing much happened. It's still debated: was it overblown panic, or a catastrophe that stayed invisible precisely because it was successfully prevented? A familiar irony in software: the reward for preventive work done well is that nothing happens.

Knight Capital (2012) — $440 million in 45 minutes

An American trading firm deployed new software to only seven of its eight servers. On the eighth, an old test routine retired years earlier was accidentally reactivated by a repurposed flag. The system began trading wildly. $440 million was lost in 45 minutes; the firm nearly went bankrupt and was sold.

The lesson: deployment inconsistency plus dead code can be devastating on its own.

Heartbleed (2014) — Two lines that opened half the internet

A missing bounds check in the OpenSSL library let attackers read arbitrary chunks of server memory — passwords, private keys. It affected a large share of the internet. The critical point: OpenSSL was a project that billions of devices depended on but almost nobody funded, maintained by a handful of volunteers.

CrowdStrike (July 2024) — One update, a global outage

A faulty content update to a security product blue-screened millions of Windows machines worldwide. Airlines cancelled flights, hospitals postponed appointments, banks stopped. The coding fault itself was small; what made it devastating was that the delivery mechanism wasn't staged — the update went to the entire world simultaneously.

The lesson: the size of a bug doesn't determine its impact. Its propagation speed does.

8. The Life Cycle of a Bug: What Happens After It's Found

In professional teams, a bug travels this path:

• 1. Report — Filed by a user, a tester, or a monitoring system.

• 2. Reproduce — The most critical step. A bug that can't be reproduced is a bug that can't be fixed. A good report contains: steps, expected result, actual result, environment details, logs/screenshots.

• 3. Triage — Assessed along two separate axes:

• Severity: How large is the technical impact? (Data loss, or a typo?)

• Priority: How urgently must it be fixed? (From a business standpoint)

These get conflated but are different: the company name misspelled on the homepage is a low-severity, high-priority bug.

• 4. Assignment and root cause analysis — You chase the cause, not the symptom.

• 5. Fix

• 6. Regression testing — Confirming the fix didn't break something else. Skip this step and your fix breeds new bugs.

• 7. Close — And ideally: an automated test is added to prevent the same bug from recurring.

Tools: Bugzilla (1998, open source, set the standard for the genre), Jira, GitHub Issues, Linear, Sentry (automatic error capture).

9. The Cost of Bugs and the "Zero Bugs" Myth

One of the oldest findings in software engineering is this: the cost of fixing a defect grows exponentially with the stage at which it's discovered. A flaw caught at the requirements stage costs almost nothing; the same flaw caught in production costs tens or hundreds of times more — because by then you're not just fixing code, but corrupted data, reputation, and customers.

That's why modern practice aims to shift left: code review, static analysis, unit tests, type systems, CI/CD gates.

So is zero bugs possible? In practice, no.

• Rice's theorem and the halting problem show that automatically verifying certain behaviors of a program in the general case is theoretically impossible.

• Testing covers only a sample of an infinite input space.

• Software "rots" as the hardware, operating system, and network beneath it change — even when the code doesn't.

There is one exception: formal verification. This approach guarantees specific properties of code by mathematical proof, and has been applied in projects like the seL4 microkernel and the CompCert compiler. But it is extremely expensive and only makes economic sense in domains where failure isn't an option — aviation, spaceflight, nuclear, medical devices.

So the industry is built not on "zero bugs" but on acceptable risk. The question isn't "are there defects?" but "which defects are tolerable, and which are never?"

10. "It's Not a Bug, It's a Feature" — A Cultural Classic

The best-known joke in software: "That's not a bug, it's a feature."

It's usually deployed by a developer on the defensive. But there's a real phenomenon behind it: some bugs become so beloved that fixing them causes a bigger problem.

One of the most famous examples is Space Invaders: the aliens speed up as their numbers dwindle. That wasn't a design decision — the hardware could simply redraw fewer objects faster. But players loved the escalating tension so much that it became one of the most iconic mechanics in game history.

There's a related law in software — Hyrum's Law: with a sufficient number of users of an API, it does not matter what you promised in the contract; every observable behavior of your system will be depended upon by somebody. Which means fixing a bug can mean breaking someone's product.

11. Bug Bounty Programs

In 1995, Netscape launched one of the first programs paying rewards to people who reported security flaws in its browser. Today Google, Apple, Microsoft, Meta, and governments pay six-figure sums for critical vulnerabilities.

The logic is simple and powerful: a security flaw has a price on the black market too. If the legal channel offers better pay and public recognition, you pull most of the people who find flaws onto the right side.

Platforms like HackerOne and Bugcrowd institutionalized this ecosystem. And so the word "bug," a name for a malfunction in the 19th century, became a profession in the 21st.

12. Bugs in the Age of AI

The last few years have added new layers to the concept:

AI is good at finding bugs. Static analysis tools are now backed by language models; code review can catch missing null checks, edge cases, and security patterns that human eyes skip. Automated test generation and fuzzing have improved markedly with LLMs.

AI is also good at producing bugs. Model-generated code can look syntactically flawless while being logically wrong. More dangerously, it looks convincing — human-written faulty code usually looks amateurish, while model output looks clean and professional. That creates a false sense of confidence in review.

A new class of bug has appeared. In classical software, the bug lives in the code. In machine learning systems, the fault may live in the training data, the model weights, data drift, or prompt design. None of these can be stepped through with a debugger. The industry is still searching for a shared vocabulary for these problems — terms in use today like "hallucination," "jailbreak," and "prompt injection" are the "bug" of the 2020s.

Maybe in a few decades someone will write an article investigating where those terms came from.

13. Frequently Asked Questions

Was the first computer bug really an insect?

No — but an insect really was found. The 1947 moth was not the source of the word, but its most famous illustration. The word had been in use since 1878.

Did Grace Hopper coin the word "bug"?

No. She didn't coin it, and probably wasn't even the person who found the moth. But she immortalized it by telling the story.

What's the difference between a bug and an error?

An error is the mistake a human makes, a bug (defect) is that mistake as it exists in the code, and a failure is the result that shows up at runtime.

Is there a non-English word for it?

In Turkish the formal equivalent is yazılım hatası ("software fault"), and debug is hata ayıklama. In everyday speech the industry mostly uses the English terms.

Can bug-free software be written?

For small, critical systems you can get close with formal verification; for large general-purpose software it's practically impossible. The goal isn't zero bugs, it's acceptable risk and fast recovery.

14. Conclusion: A 150-Year Journey of a Word

The story of the word "bug" is a small model of technology's own story.

In medieval England it was an invisible bogeyman. In 1878, in Edison's laboratory, it became the small fault an engineer couldn't get on top of. In 1947 at Harvard it took physical form as a real moth taped into a logbook. In 1996 it blew a rocket apart in mid-air, in 2012 it finished a company in 45 minutes, in 2024 it shut down the world's airports. And today there is an industry paying six-figure rewards to the people who find them.

But the word's core meaning has never changed: a bug is the thing hiding inside the system that you can't see and that torments you. Exactly the same fear as the 14th-century bogeyman.

And a programmer's job is to find that bogeyman and hold it up to the light.

Sources

• Log Book With Computer Bug — Smithsonian National Museum of American History

• Did You Know Edison Coined the Term "Bug"? — IEEE Spectrum

• The Bug in the Computer Bug Story — JSTOR Daily

• Heisenbug — Wikipedia

• List of software bugs — Wikipedia

• 11 of the most costly software errors in history — Raygun

• The Most Expensive Software Bugs in History — Techfellow

• The First Computer Bug: How A Moth Became A Tech Legend — Quantum Zeitgeist