Dealers of Lightning (27 page)

Floating point operations allow computers to handle huge numbers
by breaking them into two pieces: the mantissa, which comprises the
significant digits, and the exponent, which is a power of ten. Thus the
number 632,100,000 would be split into a mantissa of 6.321 and an
exponent of eight (i.e., 10 to the 8th power). To multiply two numbers
in a floating-point operation, the computer simply multiplies the man­tissas and sums the exponents.

Floating point functions are critical to the efficient use of a computer's
resources. But they are among the most difficult to properly implement
in hardware. Sure enough, while coding the floating point microcode
Fiala discovered a number of bugs in the PDP hardware, or at least
places where he could improve on it. Without thinking twice, he did so.
As McCreight recalled, "He figured it's his floating point, and it was up to
him to make it more accurate than the PDP's."

One of the classic frustrations of systems design is that fixing a bug in
one place often creates others elsewhere, the way squeezing a balloon
at one end makes it bulge out at the other. Something like that hap­pened in this case. When the MAXC team tried to launch a program called Interlisp that
had been written for the original PDP-10, "for some reason we couldn't
bring it up," McCreight said. "We couldn't even find
nil,
which is the first
thing you look for in Lisp—if you can't find
nil,
you're in trouble." The
problem, as they discovered after hours of tedious investigation, was that
Interlisp utilized the PDP's inefficient floating-point algorithms to exe­cute its own code. Fiala's fixes left the program hopelessly confused, as
though someone had rearranged its furniture in the dark. Unfortunately
one reason they were building MAXC was to run Lisp. So with a great
show of reluctance, Fiala acceded to pressure from the rest of the lab—
and programmed the bugs back in.

As they anticipated, Intel's 1103 memory chips proved to be a major
nuisance. The reputedly serviceable chips that survived the "turd polish­ing" stage still arrived at PARC with their deeply flawed design intact.
Among the headaches was their so-called pattern sensitivity: Certain
combinations of bits would cause an intermediate bit to "flip," so that a
sequence of 1001 might read out incorrectly as 1101 or 1011.

Thacker overcame the fault with an error correction system that could
identify and reflip erroneous bits. This worked as long as they only
occurred one at a time. Eventually, however, a second bit would fail.
"Then," Thacker recalled, "you'd get an honest error and the system
would crash and we'd have to change the chip." That was not as rare an
occurrence as it might seem. For a time MAXC boasted the largest semi­conductor memory of any computer in the world, an achievement that
temporarily made PARC Intel's single biggest customer. Approximately
25,000 of the 1103s got packed into four cabinets standing six feet high,
each one containing four card cages with sixteen circuit boards that in
turn were each about the height and width of a standard sheet of type­writer paper and held ninety-six chips apiece.

The memory boards were the only part of MAXC the lab sent out­side for fabrication. "There were so many of them—two hundred and
fifty-six, not including spares—that it was economical to make a
printed circuit board for the memory, which was not an inconsiderable
task in those days," Thacker recalled.

At one point the need for a dependable board-maker threatened to set
Thacker on a life of crime. Intel had sublicensed the manufacture of
1103s to a Canadian company called Microsystems International Ltd., or
MIL, a subsidiary of the Canadian telephone company. "They
offered to make boards at a substantially lower price than we were paying," Thacker said. "I remember going to Ottawa one time carrying a sample memory board with me, at that time a one-thousand-dollar object."

As he breezed through Canadian Customs, he was stopped
by
an offi­cer who asked what he was carrying.

"It's
a printed circuit board,"
Thacker replied.

"You'll have to pay duty on
that."

"But it's just a prototype.
I'm bringing it in
today and bringing it back
out tomorrow."

"In
that case you'll have to
pay duty both
ways. What's it worth?"

Thacker thought quickly.
"About fifteen
dollars."

"Oh,"
the officer said, waving
him
through.
"If
that's all, don't worry
about it."

Notwithstanding the stubborn
1103s, MAXC
proved a superbly robust
machine thanks to Thacker's
inspired design
and the lab's resourceful
craftsmanship. Because Thacker
had designed
in more physical memory
than was needed for all its
logical operations,
whole memory boards
could be pulled out for repair
without taking the
system down for even a
nanosecond. Once fully debugged,
the machine
set records for uninter­rupted availability on the
ARPANET, handily
outperforming computers
that had taken squadrons of
engineers years to
design. In contrast, the
Computer Science Lab at
PARC implemented MAXC
in scarcely more
than eighteen months. The cost to
Xerox was
about $750,000, of which
roughly a third went for the memory.

All
this was accomplished under
intense
deadline pressure. "Every­body was waiting for
MAXC
to
exist," recalled
McCreight, whose office
at Porter Drive was so crammed
with equipment—
six-foot-high racks
holding twenty-four spinning disks
on two
spindles, arranged one on top
and one below like pizza ovens
—there was
barely room for human
beings. "Every day guys would show up in
my
office and say,
'How
soon,
is it coming now?' So we knew it was a very much desired thing.
I
mean,
the point of the lab was to program and we couldn't program until we had
the computer system."

As
Taylor anticipated, moreover, the seemingly make-work project
paid exponential dividends in group dynamics. At first glance, devoting so
much time and money to reproducing a computer available on the open
market seemed sheer profligacy. But from Taylor’s point of view, the
assignment to produce a real machine had given his engineers a unique
opportunity to parse out their own strengths and weaknesses in ways Tay­lor could never have devised himself. What emerged at the end of the
program was a seamless, remarkably powerful unit.

"In a small group the dynamics are like those on a good basketball
team," Kay observed. "Everybody has to be able to play the whole game.
Each person should have certain things they're better at than the others,
but everyone should be pretty good at everything." MAXC proved they
were all pretty good at everything that mattered: hardware, software,
microcoding, programming. "They made having to do MAXC into a
virtue. No matter how you slice it, the job was amazing. It was not trivial.
Not even close to trivial."

It was, however, merely the first step in a long journey. MAXC was
barely finished before they started thinking about what to do next.

While his lab staff occupied themselves with imple­menting MAXC in the spring of 1971, Taylor got
around to one of the keystone tasks Pake had set down for him: He recruited his own boss.

This did not happen a moment too soon. Taylor was in critical need of
a buffer between himself and the rest of the organization. He and Pake
were still on speaking terms, but there was little more to say about their
relationship. "It was like a bad marriage where two people stay together
because of the kids," remarked Rick Jones.

No one would dispute that "the kids" were worth the effort. CSL's work
on MAXC provided just a hint of what they might be capable of once they
hit their stride. But accepting Taylors crew at this level involved a sort of
Manichean bargain: Perhaps the intellectual tension the Computer Sci­ence Lab generated on Porter Drive helped goad the other labs into
matching their energy and creativity, but they also made things harder
than was necessary. Pake, who had literally put his job on the line for
MAXC, observed privately that his efforts to build a bridge between
PARC and SDS might actually have borne fruit if only the CSL engineers
had not taken every opportunity to belittle El Segundos work. Pake's pro­clivity for solving conflicts by splitting them down the middle and Taylors
for establishing and holding his position in the local pecking order stood
in direct opposition to each other. This situation was not destined to
improve.

At least Taylor had the wisdom to see that his buffer to the outside
world should in training and experience resemble Pake more than him­self. The man in question was yet another charter member of the
ARPANET clan. In the late 1960s Jerome I. Elkind had been in charge
of computer research at Bolt, Beranek & Newman (BBN), a firm of
Boston engineering consultants known familiarly as BBN. There he had
supervised the firm’s successful bid to build a critical piece of Taylors
cherished nationwide network. This was the system of "IMPs," or Inter­face Message Processors. The IMPs formed a subnetwork of standard­ized computers (they were remodeled Honeywell minicomputers) that
stood as a gateway between each host s mainframe and the central net­work. In effect they functioned as universal translators, allowing the net­work to interconnect dozens of incompatible computers without turning
into a cacophonous Babel. (The concept, which solved one of the funda­mental technical problems bedeviling the ARPANET
'S
designers, was
the brainchild of Wes Clark.)

Thanks mostly to its extensive work on the ARPANET, Bolt, Beranek
& Newman became one of ARPA's largest private contractors. This cir­cumstance had forged an amicable relationship between Elkind and Tay­lor. Elkind also had bonds with several other PARC people, including
Butler Lampson, who he had met when his BBN division bought one of
the first SDS 940s, and Peter Deutsch, who had worked at BBN as a high
school student and during summer vacations from Berkeley.

Elkind was an empirical-minded scientist with a conspicuous streak of
skepticism. This temperament elicited sharply divergent reactions from
his peers. Some appreciated his discretion—a trait which, after all, would
not be such a drawback for the manager of a lab venturing to the edge of
the unknown. Others found him an insufferable pessimist whose disposi­tion was certain to clash sooner or later with Taylor's enthusiastic cajolery.
Even at BBN, observed Severo Ornstein, "Jerry was not universally liked
as a technical supervisor. I think he didn't have the right touch."

Taylor reassured the lab, however, that his and Elkind’s personalities
would be complementary, not contentious. He saw Elland as playing
"Mr. Outside" to his own "Mr. Inside"—as a sort of human IMP provid­ing a painless interface between CSL and PARC. Elkind could handle
the bureaucratic rubbish for which Taylor had no patience, leaving him
free to keep to his role of evangelist, guru, and all-around father figure.
Presented so abstractly, the arrangement almost seemed rational.

Taylor laid the groundwork carefully for Elkind’s recruitment. He
asked Wes Clark, an Elkind admirer from his MIT days, to pass on a
glowing recommendation to Pake, and called Elkind himself to sell him
on his Outside/Inside plan before he met with Pake. Elkind listened,
intrigued, but his understanding of the arrangement never fully matched
Taylor's. "I always thought Bob's role was to be there as a very strong asso­ciate director," he said later. "My role was that I was going to be manag­ing the lab."

It was not that Elkind was intent on micromanaging his researchers.
On the contrary, as a research chief he had always believed in granting his
best people a large measure of independence. "The style of research that
I had been used to at BBN was certainly one of very strong principal
investigators ordinarily doing work on their own," he recollected. But he
also viewed it as the managers responsibility to impose a group philoso­phy—"a vector in certain areas" so they would not be "proceeding off at
random." As for the proper vector of research at PARC, "the fact that we
were a part of Xerox meant that one would spend a great amount of time
and effort doing things that were useful to the corporation." If upon hear­ing these words Taylor felt any impulse to tell Elkind to leave the vector­ing to him, he stifled it
—
for the moment.

One glorious spring day George Pake made his way to Elkind’s house in
a quiet suburb west of Boston to take his measure. They had never met,
but everything Pake had heard about Elkind, including Wes Clark's ful­some praise, predisposed him to like the man. Over the course of a few
gratifying hours under the crisp New England sun he satisfied himself that
Elkind was everything Taylor was not: a sober scientist with indisputably
sober credentials, among them an MIT engineering doctorate (achieved
under Licklider, no less). Elkind's research experience was unassailable, as
was his experience managing large research teams in a corporate setting.
His gravity did not for a minute faze Pake, who interpreted it as serious­ness of purpose. Jerry Elkind was exactly the sort of high-caliber manager
he had dreamed about placing in charge of the labs ever since PARC had
opened its doors. (Instead he had gotten the reluctant and distracted Bill
Gunning and the academically suspect Bob Taylor.)

Yet Elkind must have sensed something vaguely eccentric about the
position he was being offered. "Why not just let Bob manage the lab?"
he asked.

"I need someone with more scientific training than just in the com­puter field," Pake replied smoothly. "The computer side is only twenty
people now, but it will grow. Once the Computer Science Lab gets to
thirty or forty scientists we'll need managers who can meld it with the
physical and information sciences." Elkind, he implied, was just that
sort of manager. Melding the labs? Bob Taylor's agenda seemed to lay
entirely in
obliterating
the other labs.

"George made it sound very exciting," Elkind recalled. "Here was a
lab that was going to be supported well and the motivation was solid. It
seemed like a very, very talented group of people had already come
there."

He came west to indulge CSL in its ritual of subjecting prospective
new members to serial interviews with the entire staff. Taylor had orig­inally established this system of vetting recruits to the team, along with
the rule that a candidate was required to win approval by a near-
unanimous vote.

"The system meant Joe Blow would have a huge advantage coming in,"
he explained, "because a whole bunch of people would have committed
themselves to his success." Subjecting their future boss to the same all-
day process was a bit on the bizarre side, but since they were already in
place and Elkind was not, they went through with it. By all accounts
Elkind acquitted himself well. "He certainly had good paper credentials
from BBN," recalled Jim Mitchell. "But I didn't know him so I went on
the basis of the interview, and he gave good interview."

Pake was cheered, if a bit surprised, to see that Elkind and Taylor
"seemed to interact pretty well. I would suspect that Taylor, who never
had a low opinion of himself,
felt
that he really didn't need this other
guy. But there was no problem
about
that, not at first."

In any event with construction
of
MAXC well under way, CSLs "vec­tor" needed no fine-tuning. If Elkind cared, or even noticed, drat most of
his new staff bypassed his office and did their brainstorming next door
with Bob Taylor, he did not show it. He did, however, recruit a cadre of
his own, raiding BBN for Daniel Bobrow and Warren Teitelman, two tal­ented Lisp programmers he encouraged
to
continue their work on artifi­cial intelligence. Bobrow, who would remain deeply loyal to Elkind
throughout the strife to come, almost immediately detected something
unsettling about CSLs ambiance. One day he confronted Taylor about it.

"I
asked him why he recruited somebody to be his own boss," he
recalled. Taylor repeated his mantra about needing someone with better
credentials to head CSL so he could be more free to exert his influence
over both computer labs, SSL included. Bobrow was not completely sat­isfied.
"I
thought he felt that, just as at ARPA he was the power behind a
lot of thrones, he could be the power behind a lot of thrones here, too,"
he observed. The unanswered question, however, was what might hap­pen if he ever got a hankering to sit on the throne himself.

If
PARC's
computer engineers thought the design and construction
of
MAXC
would place the PDP-10 controversy behind them, they
were mistaken. At Xerox headquarters the contretemps earned
PARC
a reputation for insolence it would never entirely shake. Reinforced by
a thousand further affronts over time, this would evolve into a major
handicap in its relations with headquarters in Stamford. At first, how­ever, it simply gave Xerox a pretext to pay closer attention to what the
research center was up to. The agent of this unwritten policy was a
man named Don Pendery.

A
Xerox corporate planning executive, Pendery chaired a headquar­ters task force
—
one of innumerable such bodies—devoted to monitor­ing technological changes that might affect the company's business
plan. In pursuit of the answers, he made frequent contact with the
people at PARC, who tended to regard his concerns as short-sighted
and parochial. Alan Kay, the center's self-defined futurist-in-residence,
took particular umbrage at Pendery's approach, which treated the
future largely as a Pandora's Box of threats to the bottom line. Kay and
his colleagues preferred to consider it more as a harbinger of limitless
opportunity. To scan the horizon only for hints of Xerox's future, they
thought, forced the company to ask the wrong questions and ensured
that whatever answers came would be misinterpreted or ignored.