022 | Harvard Mark II moth

“When the Bug Was Visible”

THE ARTEFACT At 15:45 on 9 September 1947, somebody troubleshooting the Harvard Mark II wrote down a component, a panel, and a cause. Then they attached the cause to the logbook with sticky tape. The famous computer bug was a moth. The important part is not that computing acquired the word ‘bug’. It did not. The important part is that, for once, the fault could be seen, removed, preserved, and filed as evidence.

The joke matters more than the legend built around it. Nobody in that room had just invented the word bug. The sentence only works because engineers were already using bug to mean a fault. A literal insect had wandered into a word that already belonged to engineering.

Nor is the surviving page a heroic portrait of one person having a sudden flash of insight. It is an operations log. A test had been running. Something failed. People traced the failure into the machine, isolated one relay, found an obstruction between its contacts, removed it, recorded what they had found, and carried on. ^[1]

That is a more useful cybersecurity artefact than the myth.

The machine around the moth

The Mark II was a large electromechanical calculator built at Harvard under Howard Aiken’s direction for the United States Navy’s Bureau of Ordnance. The Navy wanted serious computational capacity for work such as ballistic and firing-table calculations at the Naval Proving Ground at Dahlgren, Virginia. The machine was developed during the transition from wartime electromechanical calculation to the electronic computers that would soon make relay logic look slow, audible and almost architectural.^[4][5]

Where the earlier Harvard Mark I mixed relays with substantial mechanical machinery, the Mark II relied much more heavily on high-speed electromagnetic relays. Contemporary histories describe more than 13,000 of them. A relay is, at heart, a switch operated electrically: energise a coil, move an armature, open or close contacts, and thereby cause another part of the circuit to change state. Enough relays, arranged carefully enough, can perform logic and arithmetic.^[4]

They can also contain moths.

That sounds flippant only because later computers made their switching elements microscopic. In the Mark II, logical state had mechanical consequences large enough to hear and sometimes to see. Contacts moved. Relays clicked. Panels could be opened. A failed relay could be traced, inspected and replaced. The machine’s logic was abstract, but its execution remained stubbornly physical.

The Mark II was still being tested at Harvard when the moth acquired immortality. The machine was subsequently moved to Dahlgren, where Navy histories describe it entering productive operation in 1948.^[5][6] The bug therefore belongs to commissioning and shake-down, not to a mature machine quietly doing years of routine work. New systems have always found imaginative ways to turn test teams into natural historians.

A SMALL SOURCE TRAP The date is 9 September 1947. One long-circulating US Navy photograph caption gives 1945, but the Smithsonian catalogues the logbook as 1947, the surviving log page belongs to 1947, and the Mark II was not yet complete in 1945. Even official metadata can contain bugs.[1][7]

Grace Hopper, without stealing the moth

Grace Murray Hopper was part of the Harvard computing team and later became one of the most important figures in the development of programming languages. She worked on the Mark I and Mark II, wrote and taught about programming, moved into compiler development, helped shape the world in which programs could be expressed at increasingly useful levels of abstraction, and eventually retired from the US Navy as a rear admiral. None of that needs embellishment.^[2][3]

The moth story often receives some anyway.

It is routinely retold as ‘Grace Hopper found the first computer bug’. The Smithsonian is more careful: engineers working on the Mark II found the moth, Hopper was among those working on the machine, and the surviving logbook was probably not hers. In a 1969 oral-history interview Hopper herself told the story as something found by another member of the team while tracking the fault.^[1][3]

She did, however, help make the incident famous. Hopper was an exceptional speaker and storyteller. The moth became part of her explanation of early computing, and the story followed her through lectures, interviews and histories. The appropriate correction is therefore not to remove Hopper from the scene. It is to put her in the right place: a major participant in the Mark II project and a powerful populariser of the story, but not demonstrably the person who removed the moth or wrote the famous line.

Historical credit should survive contact with evidence. Hopper’s certainly does.

The word was already waiting for the insect

Engineers had called faults bugs long before digital computers. The Smithsonian notes Thomas Edison using the term for troublesome faults in engineering/telegraphy work in the 1870s, likely related to the quadruplex telegraph systems. Peggy Kidwell’s history of the expression traces a much wider engineering vocabulary in which a bug was something wrong, elusive or obstructive that had to be found and removed.^[1][8]

The related language of debugging also predates the Harvard incident. It appears in engineering and aeronautical usage before 1947. That makes the logbook annotation more, not less, charming. ‘First actual case of bug being found’ is not an etymological declaration; it’s a pun made by people who already knew exactly what a bug was supposed to mean.

This is worth being fussy about because computing history repeatedly turns good anecdotes into false origins. A memorable event becomes ‘the first’. A famous participant becomes ‘the inventor’. A surviving object becomes proof of a claim it never made. The moth did not create the language of debugging, but it did give the language an actual visible specimen.

And, unlike most metaphors, they could tape this one into the evidence file.

ETYMOLOGY VERSUS ENTOMOLOGY The earliest documented technical use currently cited by the OED appears on 15 September 1875, in the journal Operator: “‘Bugs’ on the ‘quad’ are all very well…” That sentence is particularly revealing because it treats bugs as terminology the readership already understands. The Thomas Edison Papers project argues that the usage developed around Edison’s work on quadruplex telegraphy, where troublesome false signals were called bugs, and circuitry intended to suppress them could be called a “bug trap”. So when a moth was found in the Harvard Mark II some seventy years later, the joke was not that an insect had invented the word. Engineers had been hunting bugs for decades. This time, rather unusually, one actually had wings.

The visible bug

A relay computer gives the debugger a luxury modern systems often deny: physical locality.

The Mark II had produced a symptom somewhere in a computation. The team traced that symptom through a machine made of identifiable panels, relays, contacts and wires until they reached Relay 70 on Panel F. The cause was not an incorrect formula, a misunderstood requirement, a race condition, a corrupted dependency or a cloud service returning a technically valid but operationally disastrous response. It was an insect occupying physical space where electrical contact needed to occur.

Remove insect. Restore contact. Retest.

The fault was visible in a particularly satisfying sense. The observable cause and the failed mechanism could be placed next to one another. Better still, the evidence could be retained. The logbook contains a timestamp, an affected component, an observed cause and the physical exhibit. Many modern incident records would improve substantially if they managed four out of four like this.

But visible does not mean simple. The interesting engineering work is the path from wrong answer to Relay 70. A moth becomes obvious only after the investigation has reached the correct component. Before that, the operators have a system that is not behaving as expected and thousands of possible places in which reality may have departed from design.

That is debugging: reducing uncertainty until the explanation is smaller than the symptom.

A SURPRISINGLY GOOD INCIDENT RECORD Time recorded. Component identified. Root cause described. Evidence preserved. Service restored. The famous moth is funny, but the logbook discipline is serious. It turns a transient failure into something another person can inspect later.

When the bug stopped being something you could point at

The moth arrived at an awkwardly perfect moment in computing history. Machines were moving from visible electromechanical state into electronic state, and programs were becoming large enough to develop failures that existed in logic rather than in broken physical components.

The Mark II’s program came from punched tape and its switching was performed by relays. Within a few years, stored-program electronic computers would hold instructions as data inside memory. The distinction between ‘the machine is faulty’ and ‘the instructions are faulty’ became operationally much more important. A program could fail even when every valve, transistor and later integrated circuit was working exactly as designed.

The failure could also move. A bad contact belongs somewhere. A software defect may become visible only for one input, one sequence of events, one memory layout, one timing relationship or one version of a library. Its causal location may be source code written months earlier, a generated file nobody reads, a configuration choice in another service, or an assumption shared by two components that individually behave perfectly.

We did not make bugs less physical by making computers electronic. We made the path from physical execution to human explanation longer.

Modern debugging therefore manufactures substitutes for the visibility Relay 70 once provided: logs, traces, metrics, crash dumps, packet captures, provenance, reproducible builds, test harnesses, assertions and increasingly elaborate observability platforms. These are instruments for making an invisible state leave evidence.

A system with inadequate observability may still be correct. It is merely asking its defenders to prove that by divination.

Bug is not the same as vulnerability

Cybersecurity inherited the language of bugs, then made it carry more weight than it originally possessed.

A bug is broadly a defect or unintended behaviour. A vulnerability is a condition that allows a threat actor to violate a security property such as confidentiality, integrity or availability. Many vulnerabilities arise from bugs: an out-of-bounds write, an integer error, a missing access check, an unexpected state transition. But the categories are not identical.

A system can contain a bug that merely prints the wrong total. It can also be insecure because it was designed, deliberately and without any programming error, to trust something it should not. Weak authorisation, excessive privilege, an exposed management interface or a recovery process that gives too much power to whoever can answer three biographical questions may all function precisely as specified and still be terrible security.

The moth was a fault affecting availability. It was not a hostile actor, despite achieving unauthorised persistence inside a Navy computer and defeating a relay by physical presence. Turning it into the world’s earliest APT would be funny for approximately one sentence and historically useless thereafter.

What it does teach is that system failure is not obliged to respect our organisational boundaries. Software teams like software causes. Network teams like network causes. Hardware teams like hardware causes. Security teams like adversaries. The machine remains utterly indifferent to reporting lines.

Good diagnosis keeps several hypotheses alive until the evidence kills them.

The environmental control nobody put in the architecture diagram

Hopper’s later recollection adds a detail that the polished legend often omits. In a 1969 Smithsonian oral history she remembered the Mark II building as an old structure with poor window screening, open windows, and plenty of insects. Her remembered timing does not line up perfectly with the 15:45 logbook entry, which is exactly why contemporaneous records matter, but the environmental point is plausible and revealing.^[3]

The fault ended at Relay 70. Its causal story may have begun at a window.

That is a familiar systems problem. The immediate fix restores service; the wider investigation asks why the condition was possible. Replace the failed disk, but ask why there was no redundant copy. Reboot the service, but ask why exhaustion was not bounded. Block the malicious domain, but ask why the credential still worked from an unmanaged host. Remove the moth, but perhaps also consider the path by which moths reach exposed relay contacts.

Root cause is often layered. The thing that broke the component is not necessarily the thing that made the incident likely, repeatable or consequential.

Modern security assurance has a tendency to prefer controls that fit neatly into diagrams. Environment, maintenance, housekeeping, access, power, cooling, supply chains and physical protection are less glamorous because they refuse to stay in one architectural box. The moth is an unusually photogenic reminder that the system boundary is wherever reality can influence the result.

Debugging is an evidence problem

There is another reason the logbook belongs in cybersecurity history. Debugging and incident response are both exercises in evidence under uncertainty.

A symptom is not an explanation. A machine stops. A process crashes. An account authenticates from somewhere unexpected. A detection fires. A certificate expires. A message queue grows. The first visible fact tells us what to investigate, not necessarily what happened.

The Mark II operators did not stop at ‘calculation failed’. They narrowed the system until an explanatory mechanism could be demonstrated. Then they preserved the result. The little corpse under cellophane tape is almost comically stronger evidence than the phrase ‘issue resolved’ in a ticket.

Security teams face a harder version because the environment may be adversarial. Evidence can disappear, be manipulated, arrive out of order, or be deliberately planted. A threat actor may exploit the same tendency as an intermittent software fault: vanish before the observer reaches the right place. This makes provenance and preservation part of the technical work, not administrative decoration added afterwards.

Logs need trustworthy time. Images need hashes and chain of custody. Detection rules need versioning. Analyst notes need enough context for another person to reconstruct the reasoning. Configuration snapshots matter because the system after remediation is not the system that failed. ‘We fixed it’ is not a substitute for ‘we can explain the failure’.

The moth corpse survived because somebody thought the joke worth keeping. The result is also an unusually good audit trail.

Observability is manufactured visibility

Early relay machines were, in one sense, extraordinarily observable. They were noisy, exposed, partitioned into named components, and maintained by people close enough to the hardware to recognise its rhythms. That did not make them easy to debug, but it gave investigators sensory access modern systems rarely provide.

A present-day service may execute across virtual machines, containers, managed databases, third-party identity systems, content-delivery networks and opaque cloud control planes. Nobody can open Panel F and look for the moth. The physical computer executing the failing instruction may be unknown even to the organisation that owns the data.

So visibility must be designed in advance.

That is why observability is a security property as well as an operations convenience. If defenders cannot establish what state existed, what changed, which identity performed an action, which code version ran, what data crossed a trust boundary or why a control made a decision, then detection and assurance both become weaker. The system may be secure. The organisation has merely arranged matters so that proving it will be expensive.

Conversely, more telemetry is not automatically more insight. A million events without context are the digital equivalent of standing in front of thirteen thousand relays and being told that one of them is wrong. Good observability links evidence to hypotheses. The purpose is not to record everything. It is to preserve the state needed to explain consequential behaviour.

Relay 70 had a name. Our abstractions should aspire to at least that much accountability.

What the artefact really is

The obvious artefact is the moth. It is irresistible: a literal bug, still attached to the page that made the joke. Museums could hardly ask for a friendlier object with which to explain early computing.

But the better artefact is the whole logbook entry.

The moth without the log is merely a dead insect. The log without the investigation is merely handwriting. Together they preserve the movement from symptom to component to cause. They also preserve uncertainty around authorship, a team rather than a solitary genius, a machine still being tested, and a technical culture in which faults were expected to be traced and recorded.

The page even contains its own warning against historical laziness. ‘First actual case of bug being found’ tells us, in seven words, that bug already meant something else. The famous evidence directly refutes the famous myth while sitting underneath it.

Grace Hopper did not need to invent the word bug to matter. The Mark II did not need to be the first computer to matter. The moth did not need to be the first computer fault to matter.

What happened at 15:45 is smaller and better.

A complex machine behaved incorrectly. People followed the evidence. They found the cause. They documented and preserved it. Then they went back to work.

Seventy-nine years later, that remains an excellent debugging procedure.

References & Source notes

[1] Smithsonian National Museum of American History, ‘Log Book With Computer Bug’; the surviving 1947 logbook, the moth, the wording ‘first actual case of bug being found’, and the museum’s caution that the book was probably not Hopper’s. americanhistory.si.edu

[2] Computer History Museum, ‘September 9: First Instance of Actual Computer Bug Being Found’; date, Harvard Mark II context, and Hopper’s later popularisation of the incident. computerhistory.org

[3] Smithsonian Archives Center, Grace Murray Hopper interview, 7 January 1969; Hopper’s own recollection of the Mark II building, insects, and the moth found while tracking a fault. mads.si.edu

[4] IEEE Computer Society, Howard H. Aiken; technical and historical summary of the Mark II, including its relay architecture, role, and relationship to the Mark I, III and IV. history.computer.org

[5] Office of Naval Research, A Survey of Automatic Digital Computers (1953), Harvard Mark II entry; installation at Dahlgren, operating context, and machine characteristics. bitsavers.org

[6] Naval Surface Warfare Center Dahlgren Division history; Navy requirement for large-scale calculation, Mark II procurement, arrival at Dahlgren, and ballistic-computation context. navsea.navy.mil

[7] Naval History and Heritage Command, NH 96566-KN, ‘The First Computer Bug’; photograph and Relay #70 / Panel F description. Its 1945 date conflicts with the 1947 Smithsonian record and machine chronology and is treated here as a catalogue error. history.navy.mil

[8] Peggy A. Kidwell, ‘Stalking the Elusive Computer Bug’, IEEE Annals of the History of Computing 20(4), 1998, pp. 5–9; detailed history of the engineering terms bug and debug; cited by the Smithsonian object record.
americanhistory.si.edu