What Is a Bug? The Real History of the Word

Every QA team has sat in a triage meeting looking at a ticket that says "login is buggy" and nothing else. Somebody has to guess what the reporter saw, on which build, and what they expected instead. That guessing costs a real half hour, and it happens a dozen times a sprint on a busy board.

The word at the centre of it is one we almost never examine. So: what is a bug, exactly, and where did we get that word? The history is genuinely interesting, and the famous version of it is wrong. It also turns out to matter for the way you write tickets, because the honest origin points at the one thing most bug reports leave out.

The word is much older than software

The story you hear at conferences is that a moth got into a computer in the 1940s and gave us the word. It did not. Engineers were calling faults "bugs" seventy years before that.

The clearest early evidence is Thomas Edison. In an 1878 letter he described how invention actually goes. An idea arrives in a burst, then the problems appear. Then come what he called the "little faults and difficulties", and his word for those was bugs. He used it as established slang, not as a coinage. That is the important part. He expected his reader to already know the term.

It kept showing up through the following decades:

• In 1889 a London newspaper reported that Edison had spent two nights hunting "a bug" in his phonograph.
• By 1896, an electrical handbook for tradesmen defined a bug plainly as a fault or trouble in the connections or working of an apparatus. A word only reaches a reference book after it is already common on the shop floor.
• Telegraph operators used it for interference and for faults on a line, and they were the working engineers of their day.

Where it came from before that has no settled answer. The likeliest path is the ordinary sense of an insect getting into machinery and stopping it.

The moth in the logbook, and what it actually proves

The famous incident is real. It just is not the origin.

On 9 September 1947, operators working on the Harvard Mark II found that a relay had failed. The cause was a moth caught inside Relay 70, Panel F. They removed it and taped the moth into the machine's logbook. Beside it they wrote one line: "First actual case of bug being found". The page survives, and the moth is still attached to it at the Smithsonian's National Museum of American History.

Read that log entry again and the joke is obvious. "First actual case" only lands as a joke if everyone in the room already used "bug" to mean a fault. The humour is that this time the bug was a bug. If the word had been invented that day, there would have been nothing funny to write down.

Grace Hopper worked on that machine and told the story for years afterwards, which is why her name is attached to it. She is not the source of the error. In retellings she placed it in 1945, while the logbook page is dated 1947, and the entry is not in her handwriting.

She was passing on a good workshop anecdote. It grew into an origin myth because a moth in a computer is far more memorable than a slang term in an electrician's handbook.

How it became the standard word in software

Once computing became a profession, the vocabulary came with it, because the first computer people were electrical engineers who already said bug. The verb followed. "Debugging" was in use in engineering before it was in use in programming, and it slid into software in the 1950s without anyone deciding it should.

From there it hardened into infrastructure. By the 1990s every commercial software team had a bug tracker. The word was in the name of the tool, the name of the meeting, and the job title of the person who triaged them. It also picked up a job it was never meant to do: standing in for at least five different situations that need handling differently.

So what is a bug, precisely?

Testing has a more careful vocabulary than the everyday word suggests, and it is worth keeping the parts separate:

• An error is a human mistake. A developer misreads the requirement and writes the wrong comparison.
• A defect is what that mistake leaves behind in the code or the document. This is what most people mean by bug.
• A failure is the visible event when that defect gets executed. The page returns a 500, or the total comes out wrong.
• A crash is one particular kind of failure, and only one. Plenty of expensive defects never crash anything.

So the practical definition is this. A bug is a difference between what the system does and what it was agreed the system should do. That second half is doing all the work. Without an agreement about intended behaviour, you have a surprise, not a defect.

This is why the most common argument in triage is not really about the code. Somebody says it is broken, somebody else says it works as designed, and both are describing the same behaviour accurately. What they disagree about is the specification, and neither of them has it written down anywhere they can point to.

Why the old meaning is the useful one

Here is the practical payoff of the etymology. The word makes a defect sound like an accident of nature, something that crawled in from outside while nobody was looking. Edison's usage was more honest. His bugs were the gap between the thing he intended and the thing he had built. They were his.

Treat a bug report that way and its shape changes. The report is not a complaint about behaviour. It is a claim that two things do not match, and a claim needs both halves shown:

• The build or commit, and the environment it ran on.
• The steps, specific enough that a second person gets the same result.
• What actually happened, with the evidence: the response body, the screenshot, the log line.
• What should have happened, and where that expectation comes from.

Here is what that looks like on a real board. A tester files "the app logs me out in the middle of a form" on a Thursday, three days before a release. The developer runs it, sees the session expire after 30 minutes of inactivity, and closes it as working as designed.

The tester reopens it. The signed contract promises an 8 hour session, and typing in a form is not inactivity, because no request reaches the server while you type. Two days go on that ticket. Nobody ever disagreed about the behaviour. They disagreed about a number that was written down nowhere.

The fourth item is the one that gets left out, and leaving it out is what turns a board into a backlog nobody trusts. On a team with 40 open tickets labelled bug, it is normal to find that 10 or 12 of them are really spec gaps that were never decided. They sit there for months because no amount of debugging can resolve a disagreement about intent.

The fix is not a new process. It is the expected result, written down at the same time as the case, somewhere both engineering and QA read. That is exactly the job a documented test case does, and it is why test case management is the record a release rests on.

When the expected behaviour already exists as an approved case, a bug report can point at it instead of arguing with it. The same reasoning applies to keeping an audit trail of who approved what.

Better words for the things that are not bugs

Since "bug" absorbed five meanings, the cheapest improvement most boards can make is using the other four words:

• Regression. It worked in the last release and does not now. This one deserves to jump the queue, because you already know the behaviour was agreed.
• Flake. The test fails intermittently while the product is fine. That belongs in a different pile, since flaky tests are a design problem rather than a product defect.
• Spec gap. Nobody ever decided what should happen. Needs a decision, not a developer.
• Enhancement. It does what was agreed, and what was agreed is not good enough. A real and worthwhile ticket, but a different conversation with a different owner.
• Environment issue. The staging database was out of date. Nothing to fix in the product.

Sorting a board into those five piles takes an afternoon and usually shrinks the bug count by a third without a single line of code changing. It is the same clarifying trick as separating smoke, sanity and regression runs instead of using the words interchangeably.

This is not pedantry. Each of those five piles needs a different person to act next, and one shared label hides that completely.