by Tracy Kidder
Here's how it looked to West: The company could not afford to field two new big computers; Data General had made a large investment in North Carolina as a place where major computers would be built; and although the Eclipse Group's engineers had good technical reputations, North Carolina's had better ones. The game was fixed for North Carolina and all the support groups knew it.
So West started out by calling Eagle "insurance" — it would be there in case something went wrong down south. Thus he avoided an open fight and thus he could argue that the support groups should hedge their bets and put at least a little effort into this project, too. As for North Carolina's superior reputation, West never stopped suggesting to people around Westborough that their talents had been slighted. His message was: "Let's show 'em what we can do."
"West takes lemons and makes lemonade," observed Alsing.
From the first rule — that you must compete for resources — it followed that if your group was vying with another for the right to get a new machine out the door, then you had to promise to finish yours sooner, or at least just as soon as the other team promised. West had said that the Eclipse Group would do EGO in a year. North Carolina had said, okay, they'd finish their machine in a year. In turn, West had said that Eagle would come to life in a year. West said he felt he had to pursue "what's-the-earliest-date-by-which-you-can't-prove-you-won't-be-finished" scheduling in this case. "We have to do it in a year to have any chance." But you felt obliged to set such a schedule anyway, in order to demonstrate to the ultimate bosses strong determination.
Promising to achieve a nearly impossible schedule was a way of signing up — the subject of the third rule, as I saw it. Signing up required, of course, that you fervently desire the right to build your machine and that you do whatever was necessary for success, including putting in lots of overtime, for no extra pay.
The fourth rule seemed to say that if the team succeeded, those who had signed up would get a reward. No one in the group felt certain that stock options were promised in case of success. "But it sure as hell was suggested!" said one of the Microkids. All members of the team insisted that with or without the lure of gold, they would have worked hard. But for a while, at least, the implied promise did boost spirits, which were generally high anyway.
I think that those were the rules that they were playing by, and when I recited them to some of the team's managers, they seemed to think so, too. But Alsing said there was probably another rule that stated, "One never explicitly plays by these rules." And West remarked that there was no telling which rules might be real, because only de Castro made the rules that counted, and de Castro was once quoted as saying, "Well, I guess the only good strategy is one that no one else understands."
They lived in a land of mists and mirrors. Mushroom management seemed to be practiced at all levels in their team. Or perhaps it was a version of Steve Wallach's ring protection system made flesh: West feeling uncertain about the team's real status upstairs; West's own managers never completely aware of all that their boss was up to; and the brand-new engineers kept almost completely ignorant of the real stakes, the politics, the intentions that lay behind what they were doing. But they proceeded headlong. Wallach's architectural specification was coming along nicely now. The attempt to turn those ideas into silicon and wire and microcode had begun. Now they had to create a complete design and do it in a hurry. Carman made it policy that members of the team could come and go more or less as they pleased. These were confident, aggressive young engineers — "racehorses," West liked to say — and they were about to be put under extreme pressure. Carman hoped that by allowing them to stomp out of the basement at any time without fear of reprisal, he would be providing an adequate "escape valve."
At last, by the fall of 1978, the preliminaries were complete. The kids had been hired, the general sign-up had been performed, the promises suggested, and the escape valve established. Then West turned up the steam.
You're a Microkid, like Jon Blau. You arrived that summer and now you've learned how to handle Trixie. Your immediate boss, Chuck Holland, has given you a good overall picture of the microcode to be written, and he's broken down the total job into several smaller ones and has offered you your choice. You've decided that you want to write the code for many of the arithmetic operations in Eagle's instruction set. You always liked math and feel that this will help you understand it in new, insightful ways. You've started working on your piece of the puzzle. You can see that it's a big job, but you know you can do it. Right now you're doing a lot of reading, to prepare yourself. Then one day you're sitting at your desk studying Booth's algorithm, a really nifty procedure for doing multiplication, when Alsing comes by and tells you, "There's a meeting."
You troop into a conference room with most of the other new hirees, joking, feeling a little nervous, and there waiting for you are the brass: the vice president of engineering, another lower- level but important executive, and West, sitting in a corner chewing on a toothpick. The speeches are brief. Listening intently, you hear all about the history of 32-bit superminis. These have been around awhile, but sales are really picking up. DEC's starting to turn out VAX's like jelly beans, and the word is DEC'll probably introduce a new model of VAX in about nine months. No one's saying it's your fault, but Eagle's late, very late. It really must be designed and brought to life and be ready to go by April. Really. In just six months. That won't be easy, but the brass think you can do it. That's why you were hired — you're the cream of a very fine crop. Everything depends on you now, they say.
You feel good about yourself and what you're doing when you leave that meeting. You go right back to your desk, of course, and pick up Booth's algorithm. In a little while, though, you feel you need a break. You look around for another Microkid to share coffee with you. But everyone is working, assiduously, peering into manuals and cathode-ray tubes. You go back to your reading. Then suddenly, you feel it, like a little trickle of sweat down your back. "I've gotta hurry," you say to yourself. "I've gotta get this reading done and write my code. This is just one little detail. There's a hundred of these. I better get this little piece of code done today."
Practically the next time you look up, it's midnight, but you've done what you set out to do. You leave the basement thinking: "This is life. Accomplishment. Challenges. I'm in control of a crucial part of this big machine." You look back from your car at the blank, brick, monolithic back of Building 14A/B and say to yourself, "What a great place to work." Tomorrow you'll have to get to work on an instruction called FFAS. That shouldn't be too hard. When you wake up the next morning, however, FFAS is upon you. "Oh my God! FFAS. They need that code next week. I better hurry."
"The pressure," said Blau. "I felt it from inside of me."
In another cubicle, around this time, Dave Epstein of the Hardy Boys is dreaming up the circuits of a thing called the Micro- sequencer. Nothing else will work without this piece of hardware.
Some weeks ago, Ed Rasala asked Epstein, "How long will it take you?"
Epstein replied, "About two months."
"Two months?" Rasala said. "Oh, come on."
So Epstein told him, "Okay, six weeks."
Epstein felt as if he were writing his own death warrant. Six weeks didn't look like enough time, so he's been staying here half the night working on the thing, and it's gone faster than he thought it would. This has made him so happy that just a moment ago he went down the hall and told Rasala, "Hey, Ed, I think I'm gonna do it in four weeks."
"Oh, good," Rasala said.
Now, back in his cubicle, Epstein has just realized, "I just signed up to do it in four weeks."
Better hurry, Dave.
"I don't know if I'm complaining, though," says Epstein. "I don't think I am. I work well under pressure." Indeed, Epstein will finish on schedule and his design will turn out to be almost errorless.
But not everyone works well under such conditions. Not everyone thinks it is worth it. A couple of engineers have already dr
opped out. A few are less than happy. One Hardy Boy, Josh Rosen, looks around and can hardly believe what he sees. For example, Microkids and Hardy Boys are arguing. A Microkid wants the hardware to perform a certain function. A Hardy Boy tells him, "No way — I already did my design for microcode to do that." They make a deal: "I'll encode this for you, if you'll do this other function in hardware." "All right."
What a way to design a computer! "There's no grand design," thinks Rosen. "People are just reaching out in the dark, touching hands." Rosen is having some problems with his own piece of the design. He knows he can solve them, if he's just given the time. But the managers keep saying, "There's no time." Okay, Sure. It's a rush job. But this is ridiculous. No one seems to be in control; nothing's ever explained. Foul up, however, and the managers come at you from all sides.
"The whole management structure," said Rosen. "Anyone in
Harvard Business School would have barfed."
* * *
In relatively serene times, some years before Eagle, West and his wife had made friends with an electrician who lived in their town. The man's name was Bernie. He owned a small airplane. Since West's farmhouse and barns lay under one line of approach to the little local airport, Bernie often flew over. When he did, he would waggle his wings, he might do a quick roll; sometimes he'd climb halfway out of his window and wave down at the Wests. "Bernie likes to fly upside down," West remarked, and he and his wife shook their heads and laughed.
Alsing often heard West talk about flying upside down. It seemed to mean taking large risks, and the ways in which West used the phrase left Alsing in no doubt that flying upside down was supposed to be a desirable activity — the very stuff of a vigorous life.
Ed Rasala allowed that West made life in their corner of the basement more dramatic — "definitely more dramatic" — than it usually had to be. But neither Rasala nor Alsing nor Wallach balked when West said that they had to fly upside down now. Over this project loomed the memory of EGO. No one wants to see hard work come to nothing, and EGO was generally accounted a disaster. But it had lasted just a few months and had involved only a few engineers. About thirty were working on Eagle now. That the project might be tossed on the scrap heap somewhere along the way, after months of thirty souls' passionate labor, was unthinkable. But it could certainly happen, they thought. West had felt that he had to promise to do Eagle in something like a year in order to get the chance to do it. Now he chose to believe that to get it out the door, they really had to come close to meeting that absurd schedule. At the same time, they had to do it right — right in the commercial sense. The whole project was risky, from the start. In service of the big risk, West undertook on the team's behalf many smaller ones.
"We're always assuming that things'll break right for us," observed Alsing. West was assuming, for instance, that the software resources would be there when they were needed. They were all assuming that youngsters fresh from college could build a major new computer, though none of the recruits had built anything like this before.
Looking for a technical advantage, West gambled that the coming thing in chips was a type of circuit known as a PAL. The manufacture of integrated circuits is a fairly risky business; it is said that factories can suddenly become inoperative for no apparent reason — though a small infusion of dust is a common suspect. So the conventional wisdom holds that in making a new computer, you never plan on using any sort of brand-new chip unless at least two companies are making it. At that moment, only one fairly small company was making PALs. But if PALs really were the coming thing, it would be a win to use them. West decided to do so.
West figured that the Eclipse Group had to show quick and constant progress in order to get the various arms of the company increasingly interested in helping out. For public relations, and maybe in order to keep the pressure on his crew, he made extravagant claims. He always pushed them one step ahead of themselves. Before Wallach finished specifying the architecture, West had the team designing the boards that would implement the architecture; before the engineers cleaned up their designs, West was ordering wire-wrapped, prototype boards; before the wire- wraps could possibly be made right, he was arranging for the making of printed-circuit boards; and long before anyone could know whether Eagle would become a functioning computer, West had the designers stand in front of a TV camera and describe their parts of the machine. The result of this last act of hubris was a videotaped extravaganza some twenty hours long. West planned to use it, when the right time came (if it ever did), as a tool for spreading the news of Eagle all around Westborough. "Pretty gutsy," he said, with a grin, nodding toward the shelfful of video casettes One evening West paused to say to me: "I'm flat out by definition. I'm a mess. It's terrible." A pause. "It's a lot of fun."
West established the rules for the design of Eagle and he made them stick. The team should use as little silicon as possible, a mere few thousand dollars' worth of chips. The CPU should fit on far fewer than VAX's twenty-seven boards, and each major element of the CPU should fit on a single board. If they could fulfill those requirements, Eagle would be cheaper to build than VAX. On the other hand, it had better run faster than VAX, by certain widely accepted standards. It should be capable of handling a host of terminals. A CPU is not a functioning computer system; Eagle also had to be compatible with existing lines of Data General peripherals as well as with Eclipse software.
On the Magic Marker board in his office, West wrote the following:
Not Everything Worth Doing h Worth Doing Well
Asked for a translation, he smiled and said, "If you can do a quick-and-dirty job and it works, do it." Worry, in other words, about how Eagle will look to a prospective buyer, make it an inexpensive but powerful machine and don't worry what it'll look like to the technology bigots when they peek inside. West espoused these principles of computer design: "There's a whole lot of things you've gotta do to make a successful product. The technological challenge is one thing, but you can win there and still have a disaster. You gotta give 'em guidelines so that if they follow them, they're gonna be a success. 'Do ABC and D without getting the color of the front bezel mixed up in it.'" Another precept was "No bells and whistles." And a third: "You tell a guy to do this and fit it all on one board, and I don't want to hear from him until he knows how to do it."
West reviewed all of the designs. Sometimes he slashed out features that the designers felt were useful and nice. He seemed consistently to underestimate the subtlety of what they were trying to do. All that a junior designer was likely to hear from him was "It's right," "It's wrong," or "No, there isn't time."
To some the design reviews seemed harsh and arbitrary and often technically shortsighted. Later on, though, one Hardy Boy would concede that the managers had probably known something he hadn't yet learned: that there's no such thing as a perfect design. Most experienced computer engineers I talked to agreed that absorbing this simple lesson constitutes the first step in learning how to get machines out the door. Often, they said, it is the most talented engineers who have the hardest time learning when to stop striving for perfection. West was the voice from the cave, supplying that information: "Okay. It's right. Ship it."
West kept final authority over the circuit designs. But he loosened control over most of the management of their creation. How did the Hardy Boys invent the general plan for the hardware? "Essentially," said Ed Rasala, "some of the guys and I sat down and decided what elements we needed." Over in the Microteam, though never explicitly told to do so, Chuck Holland took on the job of organizing the microding job. Holland and Ken Holberger mediated the deals between Hardy Boys and Microkids, but in general the veterans let them work things out for themselves. The entire Eclipse Group, especially its managers, seemed to be operating on instinct. Only the simplest visible arrangements existed among them. They kept no charts and graphs or organizational tables that meant anything. But those webs of voluntary, mutual responsibility, the product of many signings-up, held them together. Of
course, to a recruit it might look chaotic. Of course, someone who believed that a computer ought to be designed with long thought and a great deal of preliminary testing, and who favored rigid control, might have felt ill at the spectacle. Criticism of that sort flattered West. "Show me what I'm doing wrong," he'd say with a little smile.
In fact, the team designed the computer in something like six months, and may have set a record for speed. The task was quite complex.
The machine took its first material form in paper — in a fat volume of pages filled up with line after line of O's and l's, and in bound books large as atlases that contained the intricate geometrical depictions of the circuits, neatly drawn by their draftsman. You could think of this small library of microcode and schematics as the engineers' collected but not wholly refined thoughts on a variety of subjects. The language was esoteric, but many of the subjects were as familiar as multiplication.
I had imagined that computer engineering resembled the household electrician's work, but it seemed the bulk of it lay in making long skeins of logical connections, and it had little to do, at least at this stage, with electricity. I wondered, too, why they had to struggle to fit Eagle's CPU onto seven boards — seven was the goal — when elsewhere engineers were routinely packing entire CPUs onto single chips. The general answer was that a multi- board CPU performs simultaneously many operations that a single-chip CPU can do only sequentially. By making a CPU on several boards, you can make it run much faster than a CPU on a chip. A time was probably coming when components would operate so quickly that the distance that signals had to travel would intimately affect the speed of most commercial computers. Then miniaturization and speed would become more nearly synonymous. But that day had not yet arrived.
