Computer classes at WPI were easy for Hahn. It was a new field, and the knowledge bank wasn't yet immense. In many cases he and his fellow students knew nearly as much as their professors.

At the time, many users accessed the WPI computers by dialing through ordinary phone lines. The campus phone system wasn't particularly reliable, and users would regularly lose connections, at which point the computer would cancel their work in progress. So Hahn wrote software that would take everything the computer was doing when a call got disconnected and would save it to a file. He called the program “Freeze and Thaw” because users who were disconnected could come back, “thaw” their work, and start from where they had stopped.

His popularity soared. “Because this was an engineering school, and everybody used the computer, you affected everyone. What you did was probably right up there with changing the menu in the cafeteria,” he says.

Upon graduation, Hahn had three job offers—one from DEC, another from DEC's up-and-coming competitor Prime Computer, in Natick, Mass., and a third at a much lower salary from Bolt, Beranek & Newman, in Cambridge. He took the job at BBN, and he swears it is the smartest choice he has ever made.

Hahn liked BBN because it was the prime contractor behind the ARPANET, a high-speed data network that connected the scattered laboratories and contractors of the U.S. Defense Department's Advanced Research Projects Agency (DARPA). One of the Internet's key forerunners, the ARPANET then had no more than a few hundred connected hosts. But it was booming, adding as many as two hosts each month. (Today's Internet grows at a rate of a few million sites per month.)

“At DEC, I would have been working on the PDP-10 operating system,” Hahn says. “It was perfectly wonderful stuff, but there was nothing mystical about it.

“People working on the ARPANET, to me, were light years more evolved in thinking about computers and networking than anyone in the traditional minicomputer world.”

But he wasn't quite through with WPI. For his undergraduate thesis, he had created a paper design for a campus network that used 8-bit Zilog Z-80 microprocessors as switches, connecting users to the school's PDP-10 computer. It would let more users connect to the computer than could do so using direct phone connections. After he left, WPI decided to build the network, and Hahn offered to help. He'd drive his little green Dodge Dart the 60 kilometers to WPI and spend most of the weekend in a windowless office in the computer center, writing Z-80 assembly-language code. On Saturday night he'd crash at the house of Allan Johannesen, who worked with him on the project, or with another friend.

“He didn't get a penny for it; he didn't get aggrandizement,” says Johannesen, who ran the computer center at the time and is now VP of technology infrastructure for WPI. “He just did it because it was something he knew how to do.”

Says Debby Meredith, an executive consultant who has worked with Hahn at several companies, “If you give him free time, he'll do what makes him happy, and what makes him happy is programming.”

At BBN, Hahn was the most junior programmer in a group that worked on the interface message processor (IMP), a specialized computer that handled the comings and goings of packets of information in and out of the network. IMPs gathered packets of information coming in, performed error-checking routines, and then forwarded them on to their destinations. Today we call this a router, and companies like Cisco Systems and Juniper Networks churn them out by the millions. But in 1980 it was a work in progress. A decade earlier, BBN had built the original IMPs out of Honeywell 316 computers. Then BBN made another version of them using its own hardware, the BBN-C/30, but that system simply emulated the Honeywell 316.

Hahn was horrified. For someone who looks for beauty in code, what he found was anything but. And some things were downright ridiculous.

The Honeywell 316 was a computer without a stack—a data structure that lets program functions be queued and lets multiple functions use the same subroutines. “It was probably the last one ever built that way,” Hahn notes. “So you couldn't write a subroutine and test it and know that it would function reliably, because its behavior would change, depending on what instruction invoked it.” The BBN-C/30 copied this frustrating feature of the Honeywell exactly.

With the energy and optimism of youth, Hahn, then 20, asked his boss, Jim Herman, if he could create a new instruction set, reprogram the C/30 microcode to implement it, and then rewrite the IMP program to take advantage of the new instructions. Herman told him to go ahead. Says Hahn, “I'm guessing that he must have thought that I was nuts, but they were only paying $20 000 a year for me, so it wouldn't cost them much. And maybe something would come from it, even if they didn't actually ever put the software I wrote on the ARPANET.”

Herman recalls that he did agree with Hahn that there was a lot of stuff in the IMP software that was old and had been fussed with for way too long. And he was willing to let Hahn tackle the redesign because Hahn was a wunderkind, immensely productive, and would work it out much faster than anyone else possibly could.

Hahn worked feverishly for six months. He built a test network in the laboratory and spent virtually every waking hour there coding like crazy, then testing the program, writing down failure points, and figuring out how to fix them.