The Experiment That Became an Emergency

At about 8:30 p.m. on November 2, 1988, a program entered the early internet from a computer at MIT. The network was not the public web—there was no public web yet—but it was connected enough for a small experiment to become a large interruption.

Within a day, thousands of computers were struggling under copies of the program. The FBI later described the event as affecting roughly 6,000 of the approximately 60,000 computers then connected to the network. The program did not destroy files. It consumed attention, processing capacity, and time.

The reasonable idea

The author, Robert Tappan Morris, was trying to learn how large the network was. The idea was not absurd. The network was young, distributed, and difficult to measure. A program that moved through connected machines could, in theory, count them.

The trouble was that the program’s assumptions did not survive contact with the real network. A design meant to avoid repeated infection still created enough duplication to slow machines dramatically. The experiment had become an incident.

The detail that mattered

The most important detail was not that the program was clever. It was that the network had no mature shared response mechanism. People needed to communicate about the event while the event was degrading the communication system.

The FBI’s history of the incident describes email delays, disconnected institutions, and organizations trying to determine what had happened while their systems were already impaired. The technology problem and the coordination problem arrived together.

What came next

The incident helped establish cybersecurity as an organizational concern rather than a private hobby for system administrators. NIST’s cyber-history account explains that the Morris worm made incident-response planning a significant concern and that organizations wanted a way to communicate when the network itself was unreliable.

The response was not one magical defensive product. It was the gradual construction of teams, procedures, contact lists, and shared language.

The modern version

A small business does not need to imagine itself as a university network in 1988 to recognize the pattern. During an incident, the company’s systems may be unavailable at the same time that its normal communication channels are most needed.

The practical lesson is almost comically modest: decide who calls whom, where the instructions live, which system comes first, and how the organization communicates if the usual tools are unavailable.

The experiment became an emergency because the system was larger than the experimenter’s model. That remains one of the most reliable ways technology surprises people.