by Katie Hafner
Bidding
When ARPA’s request for proposals to build the IMP arrived at BBN in August 1968, the company had thirty days to respond. Jerry Elkind, who now was Heart’s boss, was in charge of both computer divisions. He thought BBN should bid, and he thought Heart was the best person at the company to manage it. Since the demise of the hospital computer project shortly after he had arrived, Heart had been searching for a long-term project in which to immerse himself. Moreover, Heart probably had the most experience in building the kind of computer system that ARPA was seeking. Nonetheless, when Elkind suggested he take it on, Heart was typically cautious.
Heart could be difficult to interpret at first. Alex McKenzie, who worked for Heart on and off for twenty-seven years, recalled the first time he encountered his new boss—from the other end of a hallway. Heart was speaking in a loud, high-pitched voice to someone else and seemed agitated. “He was really yelling, and I thought it must be trouble,” McKenzie recalled. “Then later I found out it was simply enthusiasm.” A few years later, while on an airplane with Heart, McKenzie finally told him about his initial impression. Heart raised his eyebrows. “YELLING?!” Heart yelled, his voice reaching for its trademark falsetto, loud enough to attract the attention of everyone around them. “I don’t yell!” Not, that is, when angry. “When he’s angry he gets very quiet,” McKenzie said.
Meetings with Heart occasionally involved a lot of shouting. “And then the next day it turns out he’s heard what you said through all the yelling and shouting,” recalled another longtime employee. “If you were willing to put up with the yelling and shouting, he made things come out right, unlike most people who yell and shout.” Heart had prodigious energy, which made it difficult for him to sit still for more than a few minutes at a time. He was most relaxed when he was at home, working in his basement woodworking shop, where he whistled long complex pieces of music flawlessly, seldom aware that he was doing so. When things were tense or uncertain, he bit his fingernails or drummed his fingers on tabletops.
Heart was intensely loyal to the people who worked for him and they in turn were loyal to him. He was also nurturing, not just toward his three children (he happily took on many child-care chores not expected of husbands in those days) but also toward his employees. At the same time, he took a lot of things personally, particularly when people left his group to go work somewhere else, even if it was only across the hall to another division.
One of Heart’s greatest strengths was making certain that jobs he signed up for really got done, and in taking on the ARPA job he was concerned about the risk of committing the company to something it might not be able to accomplish. The project was packed with uncertainties and unexplored technology. Heart found it difficult to gauge exactly what was involved. There wasn’t time to do the kind of detailed planning he’d like to do on a systems software project, such as estimating the number of lines of code that would be needed.
Risk assessment is essential in any engineering enterprise. Because no significant technological project can be entirely risk-free, the probabilities for success and failure of particular designs are factored and weighed. The potential for trouble falls into three categories: the foreseen, the unforeseen but foreseeable, and the unforeseeable. In the last case engineers are forced to make decisions with their fingers crossed. The situation facing Heart fell largely into this last category, since so much of the system had no precedent on which to base risk estimates.
The software uncertainties were serious enough, but a plethora of other unknowns existed. For example, how much traffic could such a network handle without encountering logjams? What was the chance that the failure of one node would propagate through the network? In November 1965, for example, one overloaded relay caused a ripple effect that brought down the electric power grid serving the entire northeastern United States. Above all, what was the probability that the network would even work? Signing on for a project like the ARPA network required a certain amount of sheer faith, and that disturbed Heart.
Elkind was motivated by his sense that ARPA was pushing the state of the art of computing into a new era, and from a business point of view, it made a lot of sense to launch BBN toward that future. Elkind recognized that Heart’s concerns were rational. “But it struck me that this was a contract we had to do and could do as well as anybody,” Elkind said. “We knew how to work with ARPA and had computer skills as good as anyone around.”
Elkind suggested to Heart that a small group from BBN get together to decide what to do with ARPA’s request for proposals. They agreed to meet informally and chose Danny Bobrow’s house in Belmont as the location. The first meeting went well into the night. By the time it was over, Heart was converted and BBN’s participation had been as much as guaranteed.
That was the easy part. They then had just one month to write a detailed proposal. One of the first people to get involved with the proposal was Bob Kahn, a professor of electrical engineering on leave from MIT and working in BBN’s information sciences division. At MIT, Kahn had been an applied mathematician working on communications and information theory. Most of his colleagues possessed a combination of theoretical and applied engineering skills. One day Kahn had been talking with a senior colleague at MIT about the different technical problems in which he was interested, and he asked, “How can you tell when one problem is more interesting than another?” “It’s just experience,” Kahn’s colleague responded. “How does one get that?” Kahn inquired. “Find someone who has a lot of experience and go work with him.” One obvious place for Kahn to acquire that experience was BBN. So he went.
By coincidence, in 1967, at the time that Larry Roberts was in Washington formulating the network project and its requirements, Kahn was at BBN having his own thoughts about networking. Still more coincidentally, at Jerry Elkind’s urging he had been sending unsolicited technical memos to Bob Taylor and Roberts. When Roberts told Kahn that ARPA was planning to fund a nationwide network, it was a pleasant revelation to Kahn. Then Elkind told him that a group in the BBN computer systems division was interested in putting together a proposal for the ARPA network and suggested that Kahn get involved in the process.
Not long afterward, Frank Heart wandered over to Kahn’s office. “I understand from Jerry that you’ve been thinking about the networking area. Can we chat about it?” “Yes, sure,” Kahn responded. “Who are you?” In 1968 BBN had more than six hundred employees. Frank Heart’s group occupied a row of offices along a stretch of linoleum tiled corridor in Building Number 3. At one end of the hall was a conference room with plenty of chalkboards and seating for large gatherings. The offices themselves were small and unassuming, with desks fashioned from doors to which legs had been attached by BBN’s construction shop. Stiff-backed wooden chairs and canvas-backed director’s chairs were the preferred styles. Fluorescent lighting, a few personal effects, lots of shelves and little else completed the picture.
Heart liked working with small, tightly knit groups composed of very bright people. He believed that individual productivity and talent varied not by factors of two or three, but by factors of ten or a hundred. Because Heart had a knack for spotting engineers who could make things happen, the groups he had supervised at Lincoln tended to be unusually productive.
One of the first people Heart called upon to help with the IMP proposal was Dave Walden, who had followed Heart from Lincoln to BBN. Though young, with only four or five years of programming experience, Walden had a highly cultivated expertise in realtime systems—ideal for the ARPA network job. Next Heart drafted Bernie Cosell, a young programmer who had been working in BBN’s computer systems division. Cosell was a debugger par excellence, someone who could go poking around in a computer program he had never seen before and in two days fix a problem that had gone unsolved for weeks. Heart also enlisted Hawley Rising, a soft-spoken electrical engineer who was an old friend from Heart’s student days at MIT.
Heart’s hardware ace was Severo Ornstein, a thirty-eig
ht-year-old Lincoln alumnus who had worked for Heart on and off for years. Ornstein was an intense man of many and diverse interests. The son of a virtuoso pianist and prominent composer, Ornstein had attended Harvard and had flirted briefly with a major in music before his parents argued him out of it. He finally settled on geology. After leaving Harvard, Ornstein had become interested in computers and had gone to work at Lincoln. When his colleague Wes Clark left for Washington University in St. Louis to build a computer of his own design, Ornstein went with him. After three years in St. Louis, Ornstein itched to return to Cambridge, so he called Heart, who offered him a position at BBN.
When the request for proposals arrived from ARPA, Heart handed a copy to Ornstein and said, “Why don’t you take this home and have a look at it, see what you think?” Ornstein returned to Heart’s office the next day and said, “Well, sure, I suppose we could build that if you wanted to. But I can’t see what one would want such a thing for.” Nonetheless, Ornstein thought the IMP-building project looked like fun, which was always a primary consideration for him.
Heart had a predilection for judging people not by their looks or manners or political views, but almost purely by how smart he believed them to be. Or, as he liked to put it, by how many neurons per cubic centimeter their brains contained. If he decided the number was unusually high, Heart was likely to tolerate a lot more idiosyncrasy in one than in another whose gray matter he thought was less densely packed. When talking, Heart often used computer jargon in nontechnical circumstances. “It’s a no-op,” he might say to his wife Jane if they decided to leave a Sunday afternoon free. (No-op, or no operation, refers to a line of code that accomplishes nothing.) Or he might say, “It’s binary,” to one of their small children, meaning it is a black-and-white situation.
Heart’s knack for putting together effective engineering teams had made him a highly regarded and valuable project manager. He looked for people who would be committed to a common mission rather than a personal agenda. He preferred to keep teams small so that everyone was always talking to everyone else. Heart chose the kind of people who took personal responsibility for what they did. And while Heart tolerated idiosyncrasy, he shied away from egocentric “head cases,” no matter how smart they were.
In assembling BBN’s team for the ARPA proposal, Heart made certain he pulled in engineers with all the requisite skills for such an ambitious undertaking. Kahn, for instance, was the consummate theoretician. He, more than anyone at BBN, understood the problems associated with sending information over telephone lines, and he had clear ideas about the best error-control mechanisms. Ornstein was a perfectionist, and it showed in the hardware he built, while Walden brought with him both his knowledge of real-time systems and a resolute willingness to work long hours. Cosell had the ability to burrow into complex software programs and find bugs faster than anyone else at BBN. Because of this, Cosell was one of the company’s human insurance policies: Projects would be worked on by teams, but every BBN manager knew that if his project got into trouble, he could throw Cosell into the job and superhuman things would happen in a hurry. Although there remained a great deal of detailed design work, among them the team members understood the most important technical issues.
As the team got started, Heart already knew what was in store: four weeks of working around the clock. Heart was expected home for dinner every evening at six-thirty, and he always made it. But after dinner he disappeared into his study and didn’t emerge until long after his family had gone to bed.
An important initial decision was which hardware to use. Reliability was, by far, Heart’s chief concern. His fifteen years at Lincoln Lab building antennae and radar systems for the military had taught him to worry about reliability above all else. Intuitively, Heart believed that the graduate students who would be knocking around the IMPs at the university sites wouldn’t be able to keep their hands off the equipment. He had been a student, and he had probably even done the very kinds of things he feared—hell, heknew—they would try to do. They’d go poking around in the box to see how it worked.
Heart’s choices were limited. The minicomputer industry was still relatively young. Its leaders were Digital Equipment and Honeywell. From the start, the reliability issue led Heart to favor the new Honeywell DDP-516, the machine housed in the heavy-duty steel cabinet. The Navy had a reputation for setting rigorous engineering standards. And some of BBN’s people knew some of Honeywell’s people, who made the machine at a plant not far from BBN’s Cambridge location. The 516 also helped to settle Heart’s fear that inquisitive graduate students might bring down the network with their tinkering. He could rest much easier knowing the IMPs would be housed in a box built to withstand a war.
The functionality of the Honeywell computer’s sophisticated input/output (I/O) capability—the speed and efficiency with which it could communicate with external devices such as modems—also helped propel it to the top of the list. As the handling of I/O traffic was the main function of the IMP, a machine with a good I/O structure was absolutely essential.
Not long into writing the proposal, Dave Walden began feeling that he might be out of his depth. As the first programmer Heart brought to the project, Walden did a lot of the early thinking about general coding issues, and he did some of the original charts sketching out in block form the logical flow and timing of the program. Walden had outlined enough of the program to realize they were undertaking something difficult. He decided that the ARPA proposal would provide a good excuse to recruit Will Crowther, the ingenious programmer for whom Walden had worked at Lincoln, to lead the software effort. Walden wasn’t in the least reluctant to bring in someone above him. He was confident enough in his own talents to shrug off pecking-order concerns that might worry a lot of other people. The two had worked closely at Lincoln, and Walden was happier to be on a team with Crowther than on one without him. And besides, Crowther was exceptional.
Having Crowther on the team wouldn’t just boost the chances of making the software work. Having Crowther at BBN would make doing the work more pleasant. Crowther was quiet, easy to work with, and when it came to writing code, he was downright inspiring. He was also Ornstein’s good friend and rock-climbing companion. Crowther seemed to concentrate best while hanging from door frames by his fingertips, doing chinups. And he was known for his mathematical doodling. While others passed the time at lengthy meetings by drawing squiggles and curlicues, Crowther filled his page with a thicket of differential equations.
Walden, Heart, and Ornstein were pretty sure that Crowther hadn’t been entirely happy at Lincoln since Heart had left. Crowther liked working for Heart, and while reporting to Heart at Lincoln, he had grown accustomed to seeing things built. After Heart left, a lot of the people who had worked for him had gone back to less productive tinkering. Ornstein called Crowther and said, “Willy, you ought to come to BBN,” to which Crowther readily agreed.
In Crowther, BBN gained an invaluable addition. He specialized in producing complex, tightly written pieces of code, which were exactly what was required in the IMP. In fact, writing small intricate bits of code was one of Crowther’s greatest pleasures in life. His code was among the leanest anyone who worked with him had ever seen. Since the IMPs were to be hooked up to phone lines, with data constantly flowing in and out, the idea was to have a data packet arrive at an IMP, be processed, and immediately either be sent forward or placed in a queue to await its turn—all in less time than it took to snap your fingers. Every instruction took one or two millionths of a second (microseconds) to execute. Since every unnecessary instruction ate up one or two extra microseconds, each little task, or piece of software code, had to be written with intense frugality, using the fewest instructions possible.
Central to the design of the network was the idea that the subnet of IMPs should operate invisibly. So, for instance, if someone seated at a host computer at UCLA wanted to log on to a computer at the University of Utah, the connection should appear to be direct. The user
should not have to be bothered with the fact that a subnet even existed. The effect was similar to direct dialing in the telephone system, which freed callers from the annoyance of having to wait for an operator to make their connections. Like the maze of automated switching equipment at a phone company, the IMPs were to be “transparent” to the user. As Roberts described it in the call for proposals, “Each transmitting host looks into the network through its adjacent IMP and sees itself connected to the receiving host.”
To achieve that transparency, the network was going to have to be fast, free of congestion, and extremely reliable. These were relatively straightforward requirements that Roberts had written into the request for proposals, but no one expected that actually accomplishing them would be easy.
However, one of the first things BBN’s software team discovered was that they could make the code process ten times the number of packets per second that Roberts was requiring. Before doing anything else, Crowther and Walden wrote the code for the inner loop—the heart of the program—and counted the number of instructions. Roberts would have been content with an inner loop of 1,500 instructions; Crowther and Walden used 150. From that, the two programmers calculated just how quickly the IMP could process each packet. With that information, they were able to predict how many packets could be moved per second. “We actually sat down and wrote the hundred and fifty lines of code, counted them, and then we knew,” Crowther said. They had figured out the kernel.