Grace Hopper and the Invention of the Information Age

by Kurt W Beyer

  At first Hopper and Bloch ran their own problems. “I got to the point where I knew that machine like the back of my hand,” Bloch enthusiastically recalled, “whether it was a plugging or electrical question, or questions of circuitry, debugging, or programming.”21 But the time spent running problems meant time away from defining and coding other problems. Operating Mark I quickly became the responsibility of enlisted Navy personnel,22 as the Harvard team turned to division of labor as a means of maximizing the machine’s output.

  The personnel assignments made at Harvard during the war set important precedents for future labor divisions within the general computing industry. “Coding” (later to be called “programming”) became the work of highly skilled mathematicians like Hopper and Bloch. Rudimentary tasks such as tape punching and plugboard manipulation were allocated to less skilled operators. The difference in status between coders and operators at Harvard was formally captured by military rank: coders were officers, while operators were enlisted personnel.23

  CREATING OPERATING INSTRUCTIONS

  Hopper and Bloch codified the roles and responsibilities of the new “operator” position.24 Operators managed the computation process from start to finish. They were aided by directives known as “operating instructions” that were written by Hopper and Bloch. The operating instructions, much like the main instruction tape for the machine, described the sequential steps to be performed by the operator. Plugging charts were drawn for all plugboards. For instance, the plugboard for the printer controlled the printing machine’s decimal columns. This set tab positions, vertical spaces, and horizontal spaces, and it eliminated non-significant zeros. Other plugboards controlled input card feeds, output card punches, and multiplying and dividing units. In addition, for each run a series of switches had to be set. Data switches introduced constants into the problem, while control switches controlled various machine units.

  Not only did operators have to manually set initial register, switch, and plugboard settings; these settings had to be changed after a certain number of runs. Each run required the proper manual sequencing of instruction and input tapes. Certain actions were required if an output variable reached a particular threshold value. The active involvement of operators discounted the claim that Mark I was a fully automatic calculation machine, as its official name suggested. There is no doubt that Aiken had the concept of automation as a guiding principle, but in reality the limitations inherent in the machine’s hardware required human intervention. This human-machine symbiosis produced the final results.

  The imposed division of labor permitted Mark I to operate 24 hours a day, 7 days a week. As in naval shipboard organization, operators “stood watch” for three eight-hour shifts, including midnight to 0800. Hopper and Bloch managed the watch schedule, made sure personnel were properly trained, and stepped in to deal with problems beyond the expertise of the operators. Most calls in the middle of the night dealt with troubleshooting, which effectively placed Hopper and Bloch on call 24 hours a day. The operator Robert Burns remembered in particular Bloch’s tendency to fall asleep on the other end of the phone at 2 or 3 a.m. “You’d whistle, scream, you couldn’t wake him up,” Burns recalled.25

  A sequence-control tape for Mark I, 1945. Courtesy of Harvard University Archives.

  CODING SEQUENCE CONTROL AND DATA TAPES

  Transferring code from code sheets to tapes was the most arduous part of the coding process. Hopper made the process less monotonous by assigning small teams to punch each tape. During problem L, in December 1944, Hopper assigned sequence tapes to Livingston and Verdonck and value tapes to Knowlton, Brendel, Bissel, and White. New teams were then created for quality assurance purposes. Knowlton, Brendel, and Calvin were responsible for the accuracy of the sequence tapes, and Hawkins, Bissel, and Calvin checked value tapes. The entire process, as written by Hopper in the operating instructions, was “computed, designed, coded, babied, nursed, pleaded with, and mothered by Lt. (j.g.) Grace Murray Hopper, USNR.”26

  TESTING

  With the control and data tapes produced and the operator instructions written, the moment of truth arrived. The initial run of the problem was known as a “test.” Regardless of the care and accuracy that went into coding preparation up to this point, the cool logic of the crew gave way to blind faith. To lighten the tense “moment of truth,” operator Robert Burns recalled, after a tape was prepared and placed on the machine, the crew brought out an Islamic prayer rug, faced east, and prayed that their work was not in vain.

  The “test” began with a “starting tape” that, with a single pass, enabled initial values to be fed into the 72 storage registers before the problem was run.27 Operators set and checked preliminary plugboard and switch settings, and the main sequence control tape and data tapes were loaded onto the feed mechanisms of the machine. When the Start button was pressed, the driveshaft turned, the relays clattered, and Mark I came to life. On test runs, the melodious sounds of the machine usually lasted no longer than 30 seconds before clattering to a stop. First-time successes were elusive. Instead, operators obtained complete readouts of all pertinent storage positions, which were then analyzed by Hopper and Bloch for clues. The detective work uncovered why the machine had stopped, and the process was repeated until the problem ran to completion and results were obtained.

  PACKAGING THE OUTPUT

  Two electric typewriters captured Mark I’s output. During the fall of 1944, answers streamed forth from the machine in a chaotic mass of numbers. “We hadn’t fully learned how to control the typewriter that would print an amount across a page and in blocks,” Hopper recalled. “There was so much of the techniques of handling the typewriter that had to be invented and all of the dress-up we had to learn how to do.”28

  Hopper was the first to realize that Mark I could format the presentation of results by typewriter, an minor insight at the time but one that would have considerable implications. If a computer could be used to control a typewriter, it could be used to control just about any mechanical process. One of Hopper’s initial experiments was to generate page numbers for a table of mathematical functions that the machine was producing. “At lunchtime, when Aiken was out of the office, I put a routine on which did nothing but add one and print the number and space, and made it print out just a sequence of numbers,” she recalled. “But he [Aiken] came in and found us with all $750,000 worth of Mark I adding one and printing digits—waste of computer time—oh, he went through the ceiling.”29 Eventually, Hopper convinced Aiken that it was much faster to enlist the Mark I to create page numbers and format text than sitting down at the typewriter and manually recreating the presentation of the information. Moreover, removing the human from the output process would help preserve accuracy.

  The system of coding developed by Hopper and Bloch under wartime pressure quickly and accurately defined a given problem, distilled it into mathematics that could be represented by machine code, created operating instructions to sequence an array of plugboards and switches, produced sequence control and data tapes, provided quality assurance for those tapes, tested the problem, and packaged the output. The system was embedded in a differentiated organizational structure that borrowed from shipboard and factory operations and took advantage of the efficiencies derived from the division of labor. The end result was a data-processing center that generated accurate solutions 24 hours a day, seven days a week. It is the earliest example of the type of data-processing centers that dominated the computer industry up until the 1960s and before the invention and implementation of time sharing.30

  THE FIRST HACKERS

  Within 6 months of her arrival, Lieutenant (j.g.) Grace Hopper transformed herself from a computing neophyte to an emerging expert in the field. The system of coding she developed and implemented with Richard Bloch successfully met the evergrowing demand generated by the necessities of modern warfare. The wartime setting demanded the Harvard team to work at a pace rarely experienced during peacetime. By the winter of 1945 Mar
k I was up and running 95 percent of the time, which was astonishing in view of the operational problems that plagued the ENIAC project at the University of Pennsylvania during roughly the same period.31

  Regardless of these advances in reliability, Mark I’s hardware imposed theoretical limits on speed. The rotation of the main driveshaft set the processing speed at 300 milliseconds. The rate of data and instruction input was limited to the mechanical speed of the feed mechanisms, and information had to be entered sequentially—that is, tapes could not reverse themselves in order to input a previous command or number.

  Out of sheer necessity, Hopper and Bloch began to create innovative coding techniques to augment hardware performance. “As early as 1944 we started putting together things which would make it easier to write more accurate programs and get them written faster,” Hopper recalled.32 And like so many of her computing advances throughout her career, “educated” trial and error translated into innovation. “There was no theorizing, there was no higher mathematics,” Hopper remarked. “There was no future of computers, there was nothing but get those problems going.”33 War had indeed become the mother of invention.

  With their knowledge of hardware, Hopper and Bloch realized that a little bit of programming ingenuity could maximize the machine’s processing power in the minimal number of driveshaft rotations. For instance, for an operation requiring 25 cycles, only five actually produced activity in the main bus of the machine. Hopper and Bloch began to embed additional operations within instructions, making certain that the embedded codes did not adversely affect the primary operation in progress. For instance, printing commands could be implanted within a multiplication operation. Soon it became standard practice to write programs that maximized the number of embedded instructions. As a result, processing time decreased by as much as 36 percent. Because of the relatively slow processing speed of Mark I, 36 percent could easily translate into weeks of saved run time.

  This earliest form of “hacking,”34 which produced some ingeniously efficient code, had detrimental consequences as well. For instance, the logical flow of programs embedded with extra code became extremely complicated. The flow was so complex, in fact, that often it was impossible for the operator to decipher what was happening. Hopper admitted that she was even at a loss in her attempts to deal with Bloch’s hacking. “Dick used to change the instructions on the Mark I overnight,” she recalled. “If he thought up a nice instruction to make one of his problems easier, he’d put it in and none of our tapes would run the next morning.”35

  Complex code also made it difficult to analyze the causes of machine stoppages. Both Hopper and Bloch had difficulty deciphering their own handiwork, especially if enough time had passed between writing the code and executing it. To address the problem, Hopper developed a system of documentation within her code. On the master code sheet that was used to punch the tape, she wrote notes and equations that corresponded to each line of code. Bloch and others soon picked up this practice as the Harvard team expanded, and program documentation eventually became standard practice for coders and programmers.

  Other techniques for speeding up processing time were not as refined. Hopper had a particularly interesting way to deal with “rounding off” to fewer than 23 decimal places. Instead of coding for the limited accuracy, Hopper applied her knowledge of hardware to create the desired round-off effect by reconfiguring the machine: “I pulled the relays. I pulled the lower twelve position relays in the unit.”36 This practice served her well until one night she forgot to reconnect the machine. The operators on the next shift, perplexed by Mark I’s misbehavior, called in Howard Aiken to diagnose the problem. An irate Aiken forbade Hopper or anyone else from reconfiguring the hardware to meet their coding needs.

  MOTHS IN THE MACHINE

  Of the many anecdotal stories surrounding Grace Hopper, one of the most famous concerns the discovery of the first computer “bug.” The term “bug” had been used by engineers since the time of Thomas Edison to describe mechanical malfunctions. Hopper should be given the credit for introducing the term into the language of computing and, in particular, programming. She described the events surrounding the now-infamous moth as follows:

  When we were debugging Mark II, it was over in another building, and the windows had no screens on them and we were working on it at night, of course, and all the bugs in the world came in. And, one night she [Mark II] conked out and we went to look for the bug and found an actual large moth, about four inches wing span, in one of the relays beaten to death, and we took it out and put it in the log book and pasted Scotch tape over it.37

  From that moment on, it was common practice for Hopper and the rest of the Harvard crew to inform Aiken that they were “debugging” the computer when either the hardware or the coding went amiss.

  The myth of the moth puts a playful spin on what would become a grave matter for generations of programmers. “Bugs” hidden in hardware and in software threatened to infect the early machines to such an extent that their very utility came into question. In his memoirs, the English computer pioneer Maurice Wilkes recalled the moment in 1949 when he became conscious of the debugging quandary:

  “First actual case of bug being found” as recorded in the Mark II log book on 9 September 1945. Courtesy of Smithsonian Institution.

  I well remember when this realization first came on me with full force. The EDSAC was on the top floor of the building and the tape-punching and editing equipment one floor below I was trying to get working my first non-trivial program, which was one for the numerical integration of Airy’s differential equation. It was on one of my journeys between the EDSAC room and the punching equipment that ‘hesitating at the angles of stairs’ the realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs.38

  Wilkes’s observation had significance for the future of computing because the EDSAC (Electronic Delay Storage Automatic Computer) was the first operational electronic computer with stored-program capability. But it is noteworthy that the Harvard crew came to the same conclusion 5 years earlier. Recalling the precarious period during the war, Robert Campbell lamented that bugs jeopardized the entire Mark I project: “For a while it was a very touch-and-go thing as to whether we could really keep the machine going in any kind of satisfactory way. It would seem that a new bug would develop before the bug we were looking for was found.”39 Hopper added that Mark I was subject to Murphy’s Law: anything bad that could happen to the machine did happen.40

  Hopper, Campbell, and Bloch invested substantial energy in developing practices and procedures for debugging. Like physicians, they identified symptoms, made diagnoses, and prescribed treatments. Sometimes symptoms were obvious, as when Mark I would come to a crashing halt: “The crash of that thing sounded as if a plane had run into the building,” Hopper recalled. ”You never heard such a crash in your life.”41 But most symptoms were far subtler. Incorrect results were the most troubling outcome, and the verification of output accuracy became a chore in and of itself. If accurate values previously established existed, then results were compared. But for the most part, the team needed to generate results via an alternate computation. At times Bloch went so far as to check results with a mechanical desk calculator. “The task of performing divisions accurate to 51 places on a ten-decimal digit desk machine,” he noted, “could have been termed cruel and unusual punishment!”42

  But checking every result on a desk calculator defeated the purpose of having a large, automated machine. Hopper concluded that the machine should be used to check itself as much as possible. Problems were run in two different ways, and the answers were compared. The likelihood that bugs would generate the same wrong answer was minute. This form of double checking was initiated by operators at intermediate steps throughout a problem’s run. When an error was found, Hopper and Bloch provided “rollback” procedures to find the point at which the problem went astray.

&n
bsp; HARDWARE BUGS

  If the operator determined that the code was “clean” and operating procedures were accurate, then the bug was in the hardware. This required inspecting the thousands of relays and counters, a difficult task because of the machine’s size and design. Hopper remembered that the vanity mirror in her handbag became the preferred tool to inspect the $750,000 machine:

  I always had a small mirror and one way to find the bugs in Mark I was that they were very often caused by the fraying of the brushes on the counters in which case they would spark. So they would turn out all the lights and then they would borrow my mirror and they would go along and run it and they would look for the sparks in the counters and the mirror would pick up the sparks.43

  If bugs could not be seen with Hopper’s mirror, often the trained ear could hear them. A distinct sound was emitted by Mark I’s clutch mechanism as it engaged and released every revolution. Bloch compared the sound to the clatter of a horse’s hooves on a paved street. This steady hum was accompanied with the orderly clatter of storage counters and relays banks. Different bugs resulted in distinct asynchronous rhythms. Frederick Miller, a coder who joined the Harvard crew in 1946, remembered being able to pinpoint the problem in the hardware just from the different sounds emanating from the churning machine.44