How the First Computer Bug Was Literally a Bug

A tiny moth, a room-sized calculating machine, and one wonderfully literal note in an engineering logbook created one of technology’s most enduring stories. The incident really happened at Harvard in 1947—but not quite in the way it is often retold. The insect was found inside the Harvard Mark II, not the better-known Mark I, and the word bug had already been used for technical faults long before computers existed. What made the episode memorable was not that it invented the term, but that engineers encountered an actual insect while investigating a machine problem.

Before the Moth: The Mark I and the Rise of Automatic Computing

The Harvard Mark I began as an ambitious proposal by mathematician and physicist Howard H. Aiken. Conceived in the late 1930s and built with major engineering support from IBM, it was delivered to Harvard in 1944. IBM originally called it the Automatic Sequence Controlled Calculator. It combined electromagnetic relays, mechanical counters, shafts, switches, punched cards, and paper tape to carry out long sequences of calculations automatically.

Those measurements help explain why the Mark I has become such a powerful visual symbol of early computing. It occupied an entire wall and operated with a steady chorus of clicks. Yet its significance was not merely its size. The machine could follow programmed sequences with far less human intervention than traditional desk calculators, allowing the U.S. Navy and Harvard researchers to tackle demanding mathematical work that otherwise required teams of human calculators.

Grace Hopper joined Aiken’s Harvard computing group during World War II as a U.S. Naval Reserve officer. A mathematician with a doctorate from Yale, she became one of the Mark I’s earliest programmers and helped document how the machine worked. Her later achievements in compilers and machine-independent programming languages would prove even more influential, but her connection to the moth story helped make her a household name in computing history.

What Happened on September 9, 1947?

By 1947, Harvard’s team was working with the Mark II, a successor built for the U.S. Navy. Unlike a modern solid-state computer, the Mark II depended heavily on electromechanical relays—switches that opened and closed physical electrical contacts. When the system behaved unexpectedly, the operators inspected the hardware and found a moth lodged at Relay 70 on Panel F.

The insect was removed and taped into the day’s logbook. Beside it, someone wrote:

First actual case of bug being found.

The humor makes sense only because bug was already familiar engineering slang. The note was a joke: after years of speaking figuratively about mysterious bugs in machines, the team had finally found a literal one.

The original logbook page is preserved by the Smithsonian’s National Museum of American History. It is commonly described as Grace Hopper’s logbook, but the Smithsonian attributes the discovery to the engineers working on the Mark II and notes that the book was probably not Hopper’s personal log. Hopper was part of the Harvard team and later helped preserve and popularize the anecdote, but available evidence does not establish that she personally found the moth or wrote the famous line.

The Word “Bug” Was Already Decades Old

The moth did not create the technical meaning of bug. Inventors and electrical engineers had used the word for faults, troublesome behavior, and design difficulties since at least the nineteenth century. Thomas Edison used it repeatedly in the 1870s while describing problems in telegraph, telephone, and electrical systems. By 1892, an electrical dictionary defined a bug as a fault or trouble in the operation or connections of electrical equipment.

That distinction does not make the story less interesting. In fact, it makes it richer. The incident shows engineers using humor to describe the gap between what a machine is supposed to do and what it actually does—a gap that remains central to software development today.

What Counts as a Computer Bug Today?

In everyday language, a computer bug is a defect that contributes to incorrect, unexpected, insecure, or inefficient behavior. The problem may be in source code, hardware logic, system design, requirements, configuration, data, or the interaction between several otherwise functional components.

Not every visible failure comes from one mistyped character. Modern systems are layered, connected, and highly dependent on assumptions. A defect can remain hidden until an unusual input, a specific date, heavy traffic, a race between concurrent processes, or an unexpected combination of devices activates it.

• Syntax defects: Code violates the rules of a programming language and cannot be compiled or interpreted correctly.
• Logic defects: The program runs, but its decisions or calculations produce the wrong result.
• Boundary defects: A system mishandles limits such as zero, maximum values, empty data, or date transitions.
• Integration defects: Components work independently but fail when exchanging data or timing information.
• Concurrency defects: Results depend on the unpredictable order in which simultaneous tasks execute.
• Security defects: A flaw creates conditions that may be exploitable, although not every ordinary bug becomes a vulnerability.

Technical standards often distinguish among a bug, a fault, an error, a weakness, a vulnerability, and a failure. The terms overlap in casual conversation, but they describe different stages in a chain. A defect in code or design may create an incorrect internal state; that state may eventually cause observable failure. In security, additional conditions are usually required before a defect becomes exploitable.

Debugging Is a Method, Not Just a Hunt for Typos

Debugging is the disciplined process of finding why actual behavior differs from expected behavior. Experienced developers rarely begin by changing random lines of code. They first try to make the problem repeatable and gather evidence about the circumstances that trigger it.

1. Reproduce the failure. Record the inputs, environment, sequence of actions, timing, and expected result.
2. Reduce the problem. Strip away unrelated features until the smallest reliable test case remains.
3. Inspect evidence. Study logs, traces, error messages, memory state, network activity, and recent changes.
4. Form and test a hypothesis. Predict what evidence should appear if a suspected cause is correct.
5. Repair the root cause. Avoid merely hiding the symptom or suppressing an error message.
6. Run regression tests. Confirm that the fix works and has not broken previously functioning behavior.
7. Document and monitor. Preserve the lesson, add automated checks, and watch production systems for recurrence.

Tools have changed dramatically since relay panels and paper logbooks. Developers now use interactive debuggers, automated test suites, static analysis, profilers, crash reports, distributed tracing, formal verification, and fuzz testing. The core reasoning, however, is recognizable: observe carefully, isolate variables, challenge assumptions, and verify the repair.

Famous Problems That Clarify What a Bug Is—and Is Not

The Year 2000 Problem

The Y2K problem was not one universal typo. Many systems stored years with two digits to conserve memory and storage. As 2000 approached, the value “00” could be interpreted as 1900, disrupting date comparisons, interest calculations, expiration logic, scheduling, and records shared between systems. Large-scale remediation and testing prevented the most serious predicted disruptions. Y2K is a useful example of how a design decision that once seemed practical can become hazardous when software survives longer than expected.

The Morris Worm

The 1988 Morris worm is sometimes casually grouped with famous computer bugs, but it was self-propagating software released onto the early Internet, not an accidental defect in an ordinary application. It exploited weaknesses in networked Unix systems, and its replication behavior caused widespread disruption. The episode is better understood as an early cybersecurity incident that demonstrates how software flaws, unsafe assumptions, and intentionally written code can interact.

Why Modern Systems Still Have Bugs

Software is built from abstractions layered on other abstractions. A mobile application may depend on an operating system, third-party libraries, cloud services, databases, network protocols, device sensors, authentication providers, and code written by several teams. Each layer expands what a developer can build, but it also increases the number of possible interactions.

Bugs persist because specifications are incomplete, human reasoning is limited, environments change, dependencies evolve, and users behave in ways designers did not anticipate. Testing can greatly reduce risk, but testing every possible state of a complex system is often impossible. Good engineering therefore combines prevention, detection, containment, recovery, and learning.

Why the Story Still Matters

The moth survives in popular memory because it turns an abstract concept into something visible. A software defect is normally intangible, buried in logic or hidden among millions of machine instructions. The taped insect gives the idea a body. It also captures the humility required in engineering: even an impressive machine can fail because of one overlooked interaction.

Grace Hopper’s larger legacy extends far beyond this anecdote. Her work helped advance compilers and the idea that people should be able to write programs in forms closer to human language rather than only in machine-oriented notation. The moth story remains a delightful doorway into that history, provided it is told accurately: the machine was the Mark II, the term was older than computing, and the discovery belonged to a team.

The next time an app freezes, a website behaves strangely, or an update produces an unexpected result, remember that a “bug” is not merely a nuisance. It is evidence that a system has encountered a condition its designers did not fully handle. Finding that condition—and learning from it—is how technology becomes more reliable.