What happened
The Harvard Mark II was a room-sized electromechanical computer built from relays that physically opened and closed as part of its operation.
On 9 September 1947, the team was troubleshooting a malfunction. The machine was producing incorrect results, so engineers began checking the system component by component to isolate the cause.
What they eventually found was a moth trapped inside Relay #70, Panel F. The insect physically interfered with the relay mechanism and disrupted the machine operation.
After removing it, the team taped the moth into the logbook and documented the incident. It became one of the most famous debugging stories in computing history.
Among the engineers associated with the Mark II was Grace Hopper, who later helped popularize the terms "bug" and "debugging" through lectures and public retellings of the story for decades afterward.
The part everyone gets wrong
The moth did not invent the word "bug."
Engineers had already been using the term for technical faults long before 1947. Thomas Edison used the word in the late 1800s while describing defects in his own inventions.
What made the Mark II incident memorable was that it became the perfect literal example of a bug inside a machine.
The team note about the "first actual case of bug being found" was partly a joke, but it also captured something engineers immediately recognized: systems hide small faults in places nobody expects.
Why this is the perfect QA story
Strip away the charm and the 1947 moth is still a textbook debugging and QA story.
The machine failed for a reason that was not obvious from the symptom. The team had to investigate methodically, isolate the issue, and trace the visible failure back to its real cause.
They also documented what happened instead of simply fixing it and moving on. That instinct is still the foundation of good QA work today: identify the issue clearly, preserve evidence, and make the lesson reusable for the next person.
The tools have changed since 1947, but the discipline has not.
The lesson for your product
Modern software failures usually do not involve literal moths, but the pattern is exactly the same.
Somewhere in the system there is often a hidden assumption, edge case, incorrect parameter, or overlooked condition quietly sitting between the contacts waiting for the right moment to fail.
The difference between teams that ship reliably and teams that constantly ship surprises is not luck. It is whether someone goes looking for the moth before the customer does.
A focused QA pass approaches software the same way the Mark II engineers approached Relay #70: methodically, curiously, and before the system breaks in front of the people depending on it.