Here is the story of Intermetrics' Cambridge compiler group, as I know it. Why write it down? Mostly because I have a story that I need to tell. And then there is Santayana's adage that people who do not remember history are condemned to repeat it. On the whole, I have had good times living the history of the compiler group, but I would not care to repeat the experience. Looking back on it all, I don't know which is more striking: how much things have changed, or how little things have changed. On the whole, I think that most of what is good about the compiler group has been preserved, and that much of the bad has been discarded. But forces are still at work that have led to disaster before.

Don't take anything I say too seriously; even if I wanted to be objective, I couldn't. My memory for facts and dates is a little fuzzy, and fair chunks of the story were obtained second-hand, from people who are even more biased than I. My apologies in advance to any of my fellow survivors who are offended either because I mention them by name or because I do not. Looking back on it all, I find that there was a fair amount of folly but amazingly little malice. It is easy to be wise after the fact. The problem is not to find scapegoats, but to learn from our mistakes.

I first worked at Intermetrics in the summer of 1973, four years after the company was founded, and my love-hate relationship has continued ever since, with many fits and starts. My place at Intermetrics has always been a little unusual. I was originally hired, in the best Intermetrics tradition, through nepotism: My father's cousin was one of the company's founders. Nonetheless, I was and am very much an outsider, although thanks to my longevity I have become a kind of inside outsider. My perspective is decidely odd: I was born and raised a socialist, and so I remain. None of your fly-by-night sixties radicalism; for me, socialism is as commonplace as apple pie. I have found it inadvisable to become too deeply involved in company affairs, because my fundamental values are at odds with those of Intermetrics.

Intermetrics was founded around the time of the first moon landing by five people who had worked together at Draper Lab (then the M.I.T. Instrumentation Lab) on the software for the Apollo project: John Miller, Jim Flanders, Jim Miller, Dan Lickly, and Ed Copps. They were joined shortly after by Fred Martin, who obtained a seat on the Board of Directors as a condition of employment. This group is referred to colloquially as "The Old Five plus One." Each of the founders had a very different background, temperament, and philosophy, and these differences were to be a major source of friction for many years. I sometimes think that all of the company's strengths and weaknesses can be traced to its beginning, or even before.

I wonder about the tone of the company in the very early days. People never talk about it, but I suspect that forming Intermetrics must have been a bit of a let-down. The avowed purpose of the company was to make the founders very rich, which sounds pretty exciting. But in all of human history, only one team gets to write the software for the first moon landing. How can you top a stunt like that?

In any case, the company's first big contract came through its NASA connections: to study the software development environment for the Space Shuttle. The upshot was a new language, HAL/S, and a contract to write a compiler for it. The HAL compiler was to be the company's mainstay throughout most of the seventies. It was a more or less guaranteed source of income, and it had tremendous opportunities for spinoffs. Both the Houston and the Los Angeles offices were originally formed to pursue related applications. Somewhat over half of the entire company is directly descended from the original HAL contract.

Back in Cambridge, the compiler group split up after the initial study and the prototype compiler. Dan and Fred remained in charge of the NASA business, while Jim Miller sought to diversify into other lines of work. In practice, this meant the military -- the only other organization around with the motivation and money to buy a customized compiler. So two compiler groups evolved: the NASA group, under Dan, and the DoD group, which was variously under Jim Miller and Jim Pepe.

I am not sure that it would be fair to say that there was outright animosity between the two groups, but they certainly had as little to do with each other as possible, and they evolved in diametrically opposite directions.

Part of the reason for the divergence lay in the nature of the work. In 1989, the Space Shuttle seems either mundane, tragic or ridiculous, depending on your point of view. But back then, coming off the high of the moon landing, the Shuttle had an irresistibly futuristic charm. Who has ever read a science-fiction novel where the people used throw-away rockets? Despite our better judgement, we all believed in our hearts that the Shuttle was the way of the future. It makes a difference what use your work is put to; much of the enthusiasm of the NASA group came from the glamor of the application. By contrast, the military tends to squelch even the greatest ardor; it is big and bureaucratic, and as often as not, it seems that it doesn't really want the product it is buying. The NASA group was fired by the goal of accomplishing a specific task; the DoD group had to find its satisfactions in other ways.

You also have to remember that the Vietnam War was fresh in people's minds; working for DoD was a lot less respectable then than it is now. There was a very serious political and moral divide between the people who worked for NASA and the people who worked for DoD. Of course, we all knew that the Space Shuttle had a military aspect, but people in the NASA group managed to put this fact out of their minds.

The other major difference stemmed from the temperaments of the managers. For a long time, Dan Lickly did all the hiring for the NASA group. Dan's hiring skills are legendary. It is rumored that if he talked to you about computers in your interview, it meant you weren't going to get hired. I happen to know from experience that this isn't true, although Dan certainly seemed more interested in my trip to the Canadian Rockies than in my work experience. In any case, Dan's taste in employees was uniquely his own. He hired very few people with more than a college education; he hired several people with little experience in computers, and a few who had never touched a computer. Dan hired people who had some kind of a spark, however dormant -- people who in the proper environment would work hard and effectively. Above all, he hired people who would fit into the group. The result was one of the world's most diverse, outlandish, and entertaining set of misfits.

Jim Miller, on the other hand, believed in credentials; his ideal candidate had a Ph.D. in computer science. As a result, the DoD group tended to shy away from practical work, and to lean towards the more abstract and esoteric applications. Fairly early in its history, the DoD group spawned the Bethesda office, to work on the SPL/I compiler. This probably exacerbated the difference between the two Cambridge groups, since the most practical-minded DoD people went down to Washington, leaving the theoreticians behind. The people in Cambridge ended up working first on CMS-4, the proposed new language for the Navy, and later on the proposed unified DoD language, now known as Ada. Years and years passed, and they continued their work on ever newer and better language designs, each one to be coaxed through the innumerable layers of the DoD bureaucracy. I will leave the DoD group sitting in its offices in 733 Concord Ave., and concentrate for the next few years on the NASA group, which was my group.

Dan's group really jelled when it moved into its own office space. The Golden Years lasted from 1975 to 1980, the period during which we inhabited 745 Concord Ave. Most of the group came from one of three cliques: the Bexley bunch, the Dabney House crowd, and the people from a fraternity at M.I.T. whose name I always forget. The most famous people from the fraternity were Mike Ryer and Dysak. Famous names from Dabney House at Caltech include Joe Morin, Rich Peterson, and Howie Marshall. The people who lived in Bexley House at M.I.T., or who knew them, formed by far the largest and most dynamic group, including L Hussong and his sister Laura, Kirsch, Julian, Jude, and many others. As it happens, both the Bexley and the Dabney crowds originated with a single ex-employee, Sandy Varga. So close to half of the entire group had direct or indirect connections.

There was a clear generational split between the older people, who had worked on the original HAL prototype compiler back when the company was on Green Street in Central Square, and the younger bunch who were hired as the HAL work grew. Perhaps an even more significant divide was between the married employees, who tended to form the stable older generation, and the unmarried and unwashed masses.

The younger group was incestuous and adolescent; Intermetrics was a direct continuation of college. Our lives centered around Intermetrics. We spent all of our time there, and when we weren't in the building, we were seeing each other. We worked together, played together, and slept together. (Some things don't change!) We were fiercely loyal, dedicated, and anarchic. We considered it our God-given right to show up at work any time we pleased and to leave any time we pleased. We would have been shocked at the idea that we tell anybody in advance when we planned to be absent. When we were in the building, we usually spent the first half of the day playing games. Can you throw a push-pin through a dollar bill? Throw a pencil so that it sticks in the ceiling? Can you juggle pins or balls, and if so, how many?

Crazes would take possession of the office for weeks at a time, seducing even the old and sedate. For a month, nobody did anything but play backgammon. Bridge lasted for years. L introduced the unicycle, and although I was away during the height of that fad, there was still a large hole in the wall when I came back, where somebody had crashed. I hear that it was getting quite dangerous to walk the halls. The one constant was the game of go, which used to occupy several hours a day for some dozen employees. One player estimated (probably incorrectly) that Intermetrics could field the third strongest go team in the country, after the San Francisco Go Club and the New York Go Club.

John Miller, the president, hated all of this. John is one of the kindest and most upright people I have ever met, but he is very much a victim of his background and his West Point training: Flexibility is not one of his strong points. He could never understand why anybody would want to act the way we did. What puzzled him most was how a group of maniacs like us could be the company's most productive employees.

Of course, John was missing an essential point. We were productive not despite our frivolity but because of it. If you give people perfect freedom to come and go, and trust them to do their work at their own discretion, then they start to feel terribly guilty when they slack off. If, on the other hand, you insist that people show up at 8:30 and work until 5 with a half hour off for lunch, then the clear implication is that employees can satisfy their obligations merely by showing up. At that point, the fun of the job becomes finding clever ways to look as if you are doing work.

In fact, Dan's division was a bit of a sweat shop. We may have spent four hours a day playing, but that still left eight to sleep and twelve to work. The pressure was all the more intense because it was never explicit. We worked to prove how good we were, because everybody else was doing it, and because we were all tied together by a network of intense personal loyalties with Dan at the apex.

The benefits of Dan's management style went far beyond sheer motivation. The work load is never constant -- there are always periods when you have to wait for someone else, and other times when there is a frantic rush. We played during the slack times and worked like demons during the rush times. This is management heaven. Throw away your PERT charts; the employees will compress any task to fit the schedule.

The other useful fact is that we didn't think of ourselves as "computer professionals." Many people, like me, stumbled into the computer industry more or less by accident, and we spent half of our time protesting that we had no interest in computers. This was particularly pronounced in Dan's division, but to some extent it was typical of the entire industry. Computer-science graduates only started emerging from the colleges in significant numbers some time in the mid seventies. By definition, all of the pioneers came from other disciplines.

The virtue of having "unprofessional" employees is that you avoid the Peter Principle. People on a career track are always trying to get promoted out of positions where they are competent. Especially in a fast-growing field like our own, this means that people rarely stay anywhere long enough to master the skills. Writing a code generator is very hard; to do it well requires not only intelligence and perseverance, but also skill and experience. Throughout the Golden Years, Dan's group had spectacularly low turnover. People got very good at doing what they did.

I remember three employees in particular. First was Andy Johnson, who in his own strange way was my mentor. Andy was probably the least typical person in the group: middle-aged, shy, inarticulate, a fundamentalist Christian with a weakness for off-color jokes. Andy was the most important person in the group, because he wrote and maintained the code generators for the Space Shuttle. Andy had an extraordinarily subtle mind, but there was no way to appreciate it by talking to him; you had to read his code. Everything that I know about compilers, I learned from Andy.

The second was Arra Avakian. When I first showed up at Intermetrics as a summer student, it was clear that there were two young tigers who would set Intermetrics on fire: Arra and Ron Kole. Ron went off into management, while Arra became our technical god. It probably helped that he looked a little godlike; my inside sources assure me that the women at Intermetrics voted him the most handsome man by universal acclaim. Arra specialized in everything except for compilers, although he worked on a few of those too, just to show that he could. Even today, most of the good ideas in the compiler group can be traced directly to Arra. Our whole conception of a software development environment rests on his work; the system that he built for HAL was a decade ahead of its time. He was also unbelievably fast and consistent. Many of us were fast coders, but Arra was in a class by himself; he wrote the HAL linker in two weeks. I still think of Arra as The Best Programmer in the World.

Last but not least was Don Sakahara, better known as Dysak. Dysak never occupied the same lofty heights as Andy or Arra, but nobody at Intermetrics has ever been more admired and imitated. Short, intense, and tough as nails, Dysak was the quintessential trench warrior. He scrupulously avoided anything related to management; otherwise, no task was too great or too small for him.

Dysak was synonymous with total commitment. He was meticulous to a fault. We used to joke that when Dysak gave a memo to a secretary, the typed copy came back less legible than the hand-written original. If Arra taught us how to think, Dysak taught us how to write code: Before him, nobody had ever considered putting comments in their code. When Dysak was working on a project, things had a way of going mysteriously right. Dan phrased it nicely at Dysak's going-away lunch: \*`You can count on him to get the job done, to get it done on time, and to get it done right. And there aren't very many like that.\*'

Dan's group was that rarest and most enviable kind of organization: a functioning anarchy. Things got done because everyone wanted them to get done. Dan spent most of his time in his office with his feet on the desk, reading magazines. If you went in to ask him for direction, he would listen carefully, and then, nine times out of ten, snort and go back to his magazine, implying that it was up to you to make the decision. If not for Valerie, his secretary, things would have deteriorated into total chaos. As it was, we tolerated a high degree of chaos as the price of freedom.

Anarchies are subtle, paradoxical and fragile; they can only work when there is a consensus on the key questions. The pressure to conform is much stronger in an anarchy than in a hierarchical organization. Underlying every successful anarchy is an unspoken (and unspeakable) nexus of personal power and authority. Dan was our undisputed tyrant, his power all the greater because it was exercised through indirection and inaction.

We existed as part of a larger world. People had to be hired, and Dan regarded this most crucial decision as his own prerogative. He also spent a good deal of his time and effort protecting our social setup from the pressures of the corporation. And let us never forget The Customer. All decisions about customer relations and marketing were made by Dan and Fred, to the extent that such decisions were made at all.

As time went on and the group grew larger, Dan became less interested and less capable of running the group all on his own. At this point, it became apparent that there was a huge gap in the power structure. Aside from Ron Kole, whom Dan groomed as his deputy and successor, the group had no second tier of management. It is obvious in retrospect that Dan tended to hire people who didn't want to be managers, and the people who did want to be managers tended to leave in frustration because there was no place for them between the absolute autocracy of Dan and the group's lack of formal structure. So when the crises started, there was nobody around to deal with them.

Until the late seventies, almost all of our work was a direct follow-on to the original NASA language study. Despite the cachet of working for the space program, the work itself tended to be decidedly unglamorous. The HAL compiler developed in three directions. The Flight Compiler started out with a relatively straightforward and simple-minded code generator. Over the better part of a decade, it evolved into a highly effective and finely tuned optimizing compiler. Andy Johnson got to do most of the fun work, although major portions were farmed out to Steve Gallant and Dysak. Unfortunately, the compiler suffered the fate of so much other software -- by the time it was finished, it seemed to be obsolete. In 1970, the idea of using a higher-order language for an embedded application was quite novel, and highly optimizing compilers were few and far between. By the end of the decade, compiler technology was well established, and optimizing compilers had lost much of their magical aura. Sadly, they hadn't become any easier to write.

The HAL development environment -- the simulator/debugger, the configuration management tools and so on -- fell mostly to Arra and to Craig Schulenberg in Houston. In retrospect, this work was genuinely revolutionary, but at the time, it seemed quite obvious and mundane, perhaps because Arra did it so easily.

The bulk of our work was the endless series of retargets. Each retarget required one person to beat the code generator into submission, and a small army to rewrite the runtime system and handle all of the peripheral problems. Retargeting a HAL compiler was difficult, thankless work. I remember sitting in my office for a month with the code-generator listing on my desk, despairing of ever understanding it, barely daring to open it. And then getting up the nerve to break into it, to start changing code that I didn't understand, line by line. The reward was seeing all of that mysterious machinery spring to life -- watching my own compiler perform optimizations that I had never dreamt of. An eerie experience, to say the least.

If life was hard for the retargeter, it was harder still for his assistants. The HAL compiler had a truly vast runtime library, all coded in assembly language. For each compiler-writer, there were two or three to work on the runtime library, or more for a retarget with complete I/O and real-time services. Again, difficult and thankless work, and lacking the status awarded to the retargeter. And if the retargets were bad, the rehosts were much worse. I don't even want to think about them, much less write about them.

All of this left the staff rather disgruntled. We were quite sure that we were The Best. After all, we were working for the Space Shuttle, on the very cutting edge of technology. The HAL/S and SPL/I compilers had been acclaimed (I forget by whom) the two best compilers in use. Yet we always seemed to be working on terribly mundane problems. Time was passing us by. We needed to break into new fields.

Much of the impetus came from Bruce Knobe. Bruce was the only person in the group with an academic background. He used to defend himself by pointing out that his real training was in mathematics and not computers, but he had drifted into computers like the rest of us, and had done time teaching computer science in college. Throughout his meteoric career at Intermetrics, Bruce displayed a distinctly schizophrenic leadership. He left academia because he wanted to solve real problems in the real world, but he also had a craving to explore the limits of technology. His practical persona was extremely canny and conservative, politic almost to the point of cynicism. At the same time, he was a hopeless, wide-eyed dreamer. A potent and volatile combination.

Bruce came to Intermetrics with ambitions, but he started out in a characteristically pragmatic and low-keyed way. He realized that his academic credentials would be held against him, so his first problem was to gain people's respect. He immediately took on the most difficult of jobs -- a HAL retarget. He liked to say that he approached the problem as one of maintenance. He started out with a perfectly good compiler, but it had a minor bug: It produced code for an IBM 360 instead of an NSSC-1. So without attempting to understand what the compiler actually did, he set out to fix the bug. Miraculously, he succeeded.

Having proved his competence, Bruce started to look for new worlds to conquer. The first was the retarget problem. The HAL compiler was in some sense built to be retargeted, since Andy knew that he was going to have to retarget it. But there was no physical separation between the target-independent code and the target-dependent code, and only Andy had a reliable intuition for which was which. Furthermore, the attempted HAL/S-1802 retarget had proved beyond the shadow of a doubt that there were limitations to the HAL compiler's retargetability. And in any case, the HAL compiler was beginning to look a little old-fashioned in light of the recent advances in code generation technology. It was time to try something completely different.

Bruce chose as a model the PQCC project that was going on at Carnegie-Mellon. "PQCC" stood for "Production Quality Compiler-Compiler." The idea was that you would start with formal descriptions of the language and the target machine. Then you would put them into your PQCC and turn the crank, and out would come a compiler. Not just any compiler, either, but a production-quality compiler. Needless to say, the team at CMU hadn't quite finished this task when we started to model our new series of compilers on their work.

The decision to imitate the CMU team may seem completely crazed; it is hard to imagine a less realistic goal than a PQCC. Actually, it wasn't as bad as it sounds. Both Bruce and Bill Wulff were wise and worldly enough to know that the project wasn't likely to be completed. But even an approximation of a PQCC seemed like a Good Thing. Wulff's credibility was firmly established by his Bliss-11 compiler, which was simple, effective, and completed. The PQCC work was based on the Bliss-11 compiler, which was a good sign. But despite all of these disclaimers, the fact remains that Wulff was working on an unrealistic goal, and his overweening ambition infected Intermetrics and plagued us for many years. We always tended to aim a little too high.

By this point, the compiler group had decided to go out into the world and drum up business, rather than sit around and wait for the phone to ring. We managed to procure up a few new compiler jobs, the largest and most important being the GE Fortran compiler and the GTE Pascal compiler. We bid the whole mess rather cheap on the grounds that we would achieve synergy by using the PQCC work for all of the compilers.

To make a long story short, things didn't work out as planned. There were a number of technical absurdities in the way, notably the fact that most of the compilers were to be written in Fortran, which is a non- recursive language. The PQCC work was based on tree manipulation, and there is no natural way to manipulate trees without recursion. In the best Intermetrics tradition, we went ahead and accomplished the impossible, but it wasn't easy. From one point of view, the Fortran series is a masterpiece of technical ingenuity. From another, it is a bad joke.

The GE Fortran project was supposed to pay for most of the PQCC development, but it ran into a host of problems which I would rather not discuss. In any case, the burden of the R&D fell on the GTE Pascal project, which also proceeded to get into serious trouble.

It is hard to say exactly why we had so many problems at this point in our history. The most obvious reason was the weakness in management. At this point, Dan was already starting to do his fade, and Ron Kole had taken over much of the day-to-day management of the group. Various technical types tried to manage the GTE project without much success, and things were clearly headed for disaster when Ron decided to take over control of the job. This ended up saving GTE Pascal, which was absolutely essential, but it left a big power vacuum everywhere else.

Why, you might ask, did we suddenly start to need managers, when we had done so well without them for so many years? Well, it's not so easy to change the whole direction of a group. For the last many years, we had all been tackling fairly routine tasks, and grumbling about it. The PQCC required an entirely new approach. We finally had our opportunity to break new ground, and it was essential to approach the job with an adventurous spirit. It is dangerous to unleash people's pent-up frustrations so suddenly. Everyone wanted to do everything in the best possible way, and since we were imitating a project with almost limitless ambitions, we ended up tackling a hopelessly large set of problems. Furthermore, after working on the same old stuff for so many years, everyone was seized with the desire to do things in the "modern" way. We went in one fell swoop from twiddling bits to using the most abstruse methods of data abstraction. The resulting code was unspeakably inefficient.

The next big problem was that we found ourselves quite short of bodies. After many years of slow growth, we suddenly needed to expand rapidly. We had always relied on the perfection of the hiring process, as implemented by Dan. The assumption was that anybody in the group could do anything, with maybe a few weeks to learn stuff immediately after they were hired. Of course, things never worked out quite that way. Some people were always better than others, and the assumption of universal competence was quite hard on the weaker and less experienced employees. On the whole, the sink or swim approach worked quite well, but one or two people sank, and a fair number survived with just their noses sticking out of the water.

By this point, Dan had stopped taking primary responsibility for hiring, and the old-boy network was pretty much depleted. So we started to hire in a more conventional fashion. The result was more conventional employees. People of exceptional ability continued to appear, but they were mixed with in with others who, while technically competent, lacked the spark, motivation, and self-reliance that we had come to take for granted. Or perhaps the real difference was not in the people but in the conditions. Since the demands on the employees were all unspoken, they could be taken in two ways: as a demand for everything or a demand for nothing. If you always demand the impossible, many people will come through. If you demand nothing, most people will languish. It was to be many years before we learned how to make concrete, realistic and challenging demands. In any case, once the assumption of universal competence started to break down, the process fed back upon itself.

For a while, disaster was averted. Even in decay, we were still a very strong organization. Our outrageous self-confidence wasn't entirely misplaced; we really did have a lot of unbelievably good people. The rate of growth, although fast, wasn't quite sufficient to disrupt our smooth patterns of cooperation. And after all, the whole PQCC idea wasn't completely cracked.

The GTE Pascal project probably came closest to the brink; for a while, it foreshadowed the fate of the Bromfield project. The more work they worked, the farther the job seemed from completion. It was saved by three people. Ron turned his attention to managing it, and somehow managed to get the whole thing under control. Julian moved from the linker to the "Middle End," which was in hopeless disarray. He proceeded to throw away all of the high-falutin ideas of the previous implementors, and instead, he coded the thing until it worked.

These two achievements were more or less predictable. Even if no fire had ever reached such proportions before, firefighting was a well-established tradition, and everyone knew that Ron and Julian were good. But the clincher was a stroke of blind luck. Along with the mediocre and the pretty-damned-good people who were hired to work on the GTE project, there was one superstar. After many people had made false starts, Sam Haradhvala finally managed to master the PQCC code-generation technique, discarding the impractical parts and opening up new worlds of ideas to fill in the gaps. If Sam had not been hired at a critical moment, the history of Dan's group might have been very different. As it was, we emerged from the first round of PQCC compilers sadder, little wiser, but with our pride still intact.

The years from 1979 to 1981 were full of ominous developments. I have already described how the PQCC project cracked our veneer of invincibility. The next major event was that Dan took over the DoD compiler group, officially merging the two divisions that had forked off so long ago. It was not a happy marriage. We regarded the DoD people as effete snobs who lived in an ivory tower and were incapable of doing real work. They regarded us as untutored savages who insisted on ignoring anything done in the outside world, who always reinvented the wheel, and did it badly to boot. It was the old rivalry between the hackers and the computer scientists. It was many, many years before the two groups began to see eye-to-eye; even now, you can discern the residue of the rift if you know where to look.

There was some justice on both sides. We were, indeed, aggressively anti-academic, and by being so, we certainly ignored some very useful work. The PQCC experience had demonstrated how ill-prepared we were to enter the modern world. And the DoD group did have many people with their heads in the clouds.

On the other hand, we were by no means as uncouth as we liked to pretend. We didn't go out of our way to study the literature and go to conferences and participate in the professional merry-go-round, but we were perfectly willing to look up an algorithm or even a whole new approach when called for. And some of the computer scientists in the DoD group turned out to be superlative hackers when they eventually got something to hack on.

Perhaps the most significant difference between the two groups was in their goals. Our basic objective was to satisfy the needs of our customers, and it was something we were (and are) very good at. When we built the HAL system, we didn't do it to show how well we could design languages or how well we could write compilers; we did it so that the Space Shuttle could fly. If NASA could prove to us that they needed some horrible kludge, we might grumble a little, but ultimately we were willing to see their way. The DoD group was working on Ada, and their objective was to produce the Language of the Future, the language that would satisfy everyone's needs. Perhaps a more laudable goal, but much less clearly defined, and full of pitfalls. They were necessarily less practical-minded, because their aim was more abstract. Unfortunately, this did not serve them well when they got down to the eminently practical job of writing a compiler. Bruce had gotten Dan's group off on the dangerous tack of writing the Compiler of the Future, and many of our problems stemmed precisely from the amorphous nature of that goal. But we still retained more common sense than the DoD group, and we had plenty of elbow grease.

Somewhere around this time, Dan announced the creation of the recently-defunct Department system. There were a number of reasons for doing this, one of them being that some people were getting itchy to have official recognition of their achievements, so the title of Department Manager was created for them. But the main reason was that the group had grown too big for Dan to handle; he was announcing his imminent abdication by handing over his most important job to the Department Managers: the protection of the employees and the collective lifestyle.

Just before we moved to the new building, there was a meeting to announce the beginning of the Bromfield project. The whole thing was shrouded in mystery; all that we were told was that the customer was (as we delicately say) the world's leading computer manufacturer and that even this information was top-secret and not to be divulged outside of the company or talked about within it. It was also apparent that it was going to be a big and difficult job, and that it was going to absorb many of our best people.

I felt betrayed at this meeting. I happen to have strong views on secrecy, for reasons that would take too long to explain. And here I was, effectively sworn to secrecy for an indeterminate period (which turned out to be the rest of my life) without ever having so much as agreed in principle that I would keep quiet about any aspect of Intermetrics' affairs. Of course, I had no legal obligation to keep the secret, but it was made quite clear that loose lips sink ships and that Intermetrics could suffer severely if any of us were indiscreet. Despite serious reservations, I still retained and retain enough loyalty to keep my mouth shut (mostly).

I pointed out at the meeting that having a secret project in our midst was sure to destroy the social fabric of the group, which was our most precious asset. As it turned out, the Bromfield project did precisely that, although not for quite the reasons that I had anticipated. My dissent at this meeting was another omen. We are now accustomed to criticizing everything and everyone, but in the Golden Years we reserved our criticism for The Company (John Miller) and our praise for The Group (Dan). We expressed some reservations to each other privately, but in public we maintained solidarity. I was the first person to criticize our own management so strongly and so publicly, and I caught a good deal of flack for doing so (not from Dan, of course, but from my peers). A few years later, bitter words would be heard on everyone's lips.

Finally came the great symbolic act: We abandoned our beloved home and castle in 745 and moved into the New Building together with the rest of the company. By this time, our group had grown far too large to fit in 745; we had colonized 737 next door and even spilled over into the main building (701). Still, there was a coziness and security that spread out from our headquarters in 745; as long as we had our home base, we could defy the rest of the company. We lost this when we moved into the big echoing sterile corridors of 733. For a few years, we tried desperately to hang on to the old ways: We would juggle in the halls and pitch pennies onto the rafters in the Atrium, and climb up to retrieve them. But we could not keep it up for long; the character of the building, the omnipresence of the rest of the company, the changes in our own group and the changing times finally accomplished what John Miller had striven to do unsuccessfully for the better part of a decade; they made us into a bunch of respectable professionals.

One of the more subtle means by which the new building changed us was that we finally had enough space. We had always been ridiculously crowded. There were a handful of people with single offices, which were little bigger than closets, but most of us lived in doubles, triples, quads or quints.

It was fun. Privacy was the last thing that we wanted, and the crowding gave us a feeling of shared hardship that held us all the more tightly together. My favorite office was the one in the back room in 745, which I shared with Jude, Laura, Ken Nappa and Gail. It had four desks, and was about the size of one of our larger doubles. There were also a couple of other people who officially shared the office, but they mostly showed up at night, if at all, so they didn't count for much. It was the Place to Be -- we installed a dart board and a few other gadgets, and everyone came to visit us.

Then there was the matter of terminals. Back in the early 70's computer resources were very expensive. We did lots of work at our desks with listings, and overnight turnaround was the accepted norm. In 745, we had some dozen terminals, most of them packed into the big common room. There may have been a few exceptions. As I remember, Arra always had a terminal in his office. He even had a terminal at home, which was really radical. But of course, nobody grudged him his privilege. Most of us did our work in the common room. It was a great way to learn things. If you had a question, you didn't try to figure it out for yourself: You asked your neighbor. I learned to write CLISTs by looking over Andy's shoulder; Ron taught me how to write JCL, and Jude taught me Unix. As time went on, more and more people got terminals in their offices, and when we moved to 733, many people had single offices with terminals. Work stopped being a collective effort and became more of a private affair. It was particularly hard on the new employees. In 745, a new hire was forced, like it or not, to work surrounded by people, and he or she quickly learned who knew what and how to ask questions. In 733, new employees were on their own. People would have helped them if they had asked, but they didn't know whom to go to, and many lacked the courage to find out.

Meanwhile, other things were cooking. In the early years, the Old Five plus One had jealously guarded their powers and prerogatives, to the disgust of the next generation. It is probably fair to say that Intermetrics' branch offices were formed to give younger people a place to exercise their ambitions. The branch offices' resentment of the Cambridge office was, and is, quite palpable.

The founders had conservative business instincts; their trademarks were caution and incrementalism. In any case, the company simply didn't have enough money to strike out in genuinely new directions. Towards the end of the seventies, things began to change. Some of the branch offices (notably California) had become quite large and powerful, which naturally tended to tip the balance of power away from the old guard. The whole business climate was changing; it was boom time for the computer industry, and everyone was swept along in the wave of expansionism. Finally, the founders were getting a little tired; they had founded Intermetrics to get rich, and after running the company for a decade, it was time to realize their dream. They were eager to sell out and retire.

Just as Dan began to relinquish control of the compiler group, so the old guard began to relinquish control throughout the company. The long-suppressed ambitions of the next generation were unleashed. Unfortunately, they didn't have the experience and wisdom to match their desires. Furthermore, although Intermetrics had become much larger and richer, it didn't have anywhere near enough money to finance all of the dreams of the young Turks. Nobody in upper management wanted to be unfair or to make hard decisions, so everyone was funded at an inadequate level.

SPD, which began to creep into existence somewhere around this time, was a prime example. Various people had concluded that the market was ripe for a moderate-cost, moderate-quality compiler family dedicated to embedded applications. Intermetrics had the necessary skills and expertise in spades; all that was needed was to pursue this goal aggressively, and everyone could get rich. However, there was no way that Intermetrics was going to plop down the money to do the job right. Instead, Jude was assigned the unenviable task of producing the cheapest possible compiler. This he did by adding an extra phase onto an existing Pascal compiler to translate PDP-11 assembly language into 8086 code. An approach which, as he himself pointed out, could not possibly yield acceptable results. Later, SPD managed to achieve some external funding by teaming up with Gould, but the history of SPD has always been marked by chronic lack of money. By the time the SPD compiler had become a respectable product, plenty of competitors were already well established.

So the boom years started, and the original character of Dan's group was lost forever. I remember feeling like the Goose Who Layed the Golden Eggs. For years and years we had provided most of Intermetrics' revenue, and now the Powers that Were had decided to cash in, to slit our belly open and grab all the eggs at once. One of the reasons that I preserve relative equanimity now while everyone around me complains is that nothing can possibly match the bitterness of the early eighties. Everything that we loved and cherished was evaporating around us.

Dan's group had nourished a collection of illusions that made a certain amount of sense in the early years but lasted far too long. The illusions were self-fulfilling: As long as they could be sustained, they created their own reality. But once the assumptions started to be called into question, the whole structure crumbled.

We were so dedicated! But why? What did we get out of it? Dedication is its own reward, but when we woke up to sober reality, we found that we were underpaid and overworked.

We were so sure that we were the best! Nothing was beyond us. Merely difficult tasks were beneath us; we thrived on the impossible. We were invincible! Pride, indeed, goes before a fall.

We were adolescents verging on middle age, a vestige of the sixties on the verge of the eighties. Boston was changing from a funky college town with a decaying industrial base to a booming high-tech center full of well-heeled yuppies. Computer programming was no longer the property of a small group of eccentrics; it was a mainstream occupation. Our remarkable achievements were no longer so remarkable.

People started to leave en masse, something that would have been unthinkable in the Golden Years. In the seventies, someone would vanish every now and then, to go to school or maybe to move to another part of the country, or even occasionally to go to another job in the same field and in the same geographical area. (But why would anyone want to do that? Weren't we The Best?) The exodus that started in the eighties was more like rats leaving a sinking ship.

And just as people started leaving, the demand for bodies became really critical. In the seventies, a ten-person project was considered huge. By the time the Bromfield Back End had staffed up, it was at least twice that size. Meanwhile, the Ada job had started -- an incredibly ambitious set of compilers and development tools, all bid fixed-price. People are probably unwilling to remember this fact, but management was very happy that the jobs were fixed-price; they had become impatient with the sure but small profits to be achieved by cost-plus jobs. Again, we were to achieve great savings through symbiosis, using the PQCC technology. We were going to make a killing.

The compiler group might have been able to do either the Bromfield job or the Ada job, but there was no way that we could possibly do both at once, especially considering that many people refused to work on Ada because it was for the DoD, and that many others were reluctant to work on Bromfield because it was secret, and too big. I was caught between a rock and a hard place in those years, because I was not merely reluctant but unwilling on principle to work both on Ada and on Bromfield. I barely managed to eke out enough work to do, and finally ending up compromising and working on Prime Ada for a while. It might have been Ada, but at least the customer was commercial, and my best friend at Intermetrics was in charge of the job and needed me desperately.

So Ada and Bromfield both began to hire furiously. All things considered, it is miraculous that they found as many good people as they did, but there was no way that they could hire at that rate and still keep up the standards. And whatever the quality of the people that were hired, the groups were growing far too fast for the new people to be integrated properly. Communications fell apart, people started wandering around with dazed looks, and everyone was miserable. When the Bromfield Front End came in -- a bona-fide black hole capable of swallowing all of the programmers in the Commonwealth of Massachusetts -- the situation changed from ridiculous to a run-away catastrophe.

I will touch only lightly on the history of the Ada and Bromfield jobs, although they were almost all of what went on in the first half of the eighties. The stories are fascinating and ripe with object lessons, but they do not make pleasant telling. Besides, I stayed as far away from Ada and Bromfield as I could, and the secrecy surrounding Bromfield was surprisingly effective. Other people can tell these stories better than I.

Somewhere around 1983, Dan gave up the pretence of running the group, and it eventually split into six separate pieces. Three of them split off relatively early. First was Documentation. The Documentation group was formed because Valerie, was fed up with being Dan's secretary while all of her friends had glamorous-sounding jobs. And if anyone deserved a good break, it was Valerie: It was a standing joke that she was the one who really ran our group, and the joke had a good deal of truth to it.

Second came the Software Products Division (SPD): this was Ron Kole's baby. I have already described some of the problems that SPD had, and maybe still has. Again, I do not want to go into SPD in too much detail; it is bad luck talking about history while it is still in the making. But despite its problems, SPD became a haven for the old 745 crowd. SPD offered an informal environment, a chance to work with uniformly brilliant people, and a chance to see the fruits of your labors. Above all, SPD was small. SPD turned out to be the last stop for many people on their way out of Intermetrics: Dan, Arra and Dysak all worked for SPD at the point that they quit, as did a host of lesser luminaries.

Third came the Computer Facilities Division (CFD). As the official hackers, Dan's group had naturally taken care of the computer hardware and software not only for ourselves but for most of the company. Somewhere along the line, CFD formally became a separate entity. Like Documentation and SPD, CFD was relatively small, and retained much of the original character of Dan's group.

This left the main body of the compiler group, which eventually split into three separate divisions: Bromfield, Ada, and Everything Else. I, of course, worked for Everything Else, under Rone Hubbard. We had the tail end of the HAL work to do, some follow-on Fortran compilers, and a few other odd jobs. But the only significant new work that we landed (or should I say stole from Bethesda?) was the CHILL compiler. CHILL was an elite job, with its promise of travel to and residence in England, and it got an elite staff. We managed for the first time to build a PQCC compiler without any serious pain, and within the CHILL project, the old joys survived of working closely with a small number of good people on a hard job.

Each of the six groups suffered from empire building, the bane of Intermetrics. Intermetrics has aptly been described as a feudal organization; each division head receives virtually unlimited autonomy in return for a pledge of loyalty and a promise to make money. The system has great strengths and weaknesses. One of the weaknesses is that it encourages a process of reckless self-aggrandizement. This has led to disaster time and again in many different parts of the company.

As long as Dan held sway, our group was immune to this effect. Dan brooked no rivals. And he himself had nothing to prove; he had his empire from the beginning, and he had little desire to expand it. When Dan relinquished control, many people jumped in and began to scramble for the pieces. Although they had, or thought they had, eminently laudable intentions, the net effect was total disregard for the good of the whole, and even for the long-term good of the components.

The Ada project proceeded to repeat all of the mistakes of the GTE Pascal project, but magnified by an order of magnitude. Just why Ada got into so much trouble is a difficult and important question. The project certainly had no lack of brilliant people. Perhaps part of its problem, like Bromfield, was that it had too many brilliant people, too many prima donnas. In the Golden Years, we spent plenty of time arguing with each other, but we also had a fairly clearly defined pecking order. Ultimately, everyone would defer (for instance) to Arra. It was relatively easy for us to reach consensus, and once we did so, we all pulled in the same direction. After all, we were just hackers, not computer scientists: We had no axes to grind. Within the Ada project, no consensus was ever reached, or not until the very end. Different parts of the project pulled in different directions, and the whole thing would lurch back and forth as first one group and then another gained the ascendancy. There weren't enough Dysak types: people who would sit down, shut up, and get the job done. Get it done not grudgingly or ploddingly, but with dash and flair. But Dysak didn't work on military jobs.

Ada also had no real managers. For a long time, they tried to run the job the only way they knew how, as a Dan-style anarchy. But the whole spirit of the project was wrong for this style of management, and in any case, the problem was simply too large and complex to be able to get away with such a lack of structure. Time passed, and the project grew and grew and got later and later, and being a fixed-price job, it lost more and more money.

Bromfield, I gather, ran into very similar problems. Things got so bad that several of the key people on the job literally refused to talk to each other. The Back End eventually got done, but when the Front End came in, it turned into the classic nightmare project -- the tar pit on the front of The Mythical Man-Month. Rather ironic, considering the contents of that book and the identity of Mr. Bromfield. Everyone knew perfectly well that the tar pit was there; they walked in with their eyes open. Theirs not to reason why... And indeed, the company made a ton of money off the Bromfield project.

And then, out of the blue, Bromfield was canceled, and the better part of a hundred people had nothing to do. It is generally agreed that this was the best thing that could possibly have happened. Better for the job to be canceled with seventy employees than with seven hundred. The vast pool of talent freed when Bromfield was canceled finally made it possible to think seriously about completing the Ada job. The cream of Bromfield were very, very good indeed.

However, this still left a huge number of people twiddling their thumbs. Rone had failed to bring in any major new work after CHILL, and Ada had plenty of slots to fill but no money to pay for them. So everyone could see that massive layoffs were just around the corner. The exodus continued apace.

The layoffs happened in three rounds, each one cutting deeper. In the first round, the idea was to fire only people who should never have been hired, or who for one or another reason had never managed to fit into a productive role. Some mistakes were probably made, but on the whole it worked out as planned. By the third round of layoffs, old and valued employees were being fired -- even people for whom there was an immediate and pressing need. The whole process was unspeakably painful, not least for the managers who had to name names. And it was incredibly drawn out. The layoffs stretched over a couple of years, and each round was big enough to hurt badly and small enough not to reassure anyone that the layoffs were over.

Two of the casualties of the layoffs were John Miller and Fred Martin. (Fred was still nominally in charge of all the troubled groups.) It was very sad for me seeing John announce the layoffs and his resignation as President. That whole endless battle between Dan and John seemed so trivial. Dan and John fought furiously, but they had a fundamental thing in common: They really cared about the employees. It just happened that their views about what was good for the employees were diametrically opposed. John was so sincere in his belief that what was good for Intermetrics, what was good for the military, what was good for the country, and what was good for the employees were all the same. He couldn't bear having to fire so many people. But true to character to the last, he stood up like a mensch and took responsibility.

Things would have been much worse if Rone hadn't managed to land the Delco job just before he was sacrificed. (It is still a mystery to me why Rone got the shortest end of the stick among the three division heads, when his group was the one least responsible for the problems.) Between Ada and Delco and SPD, there was just enough work to keep the compiler group alive.

The new management got much of the blame for the layoffs, but this was wholly unjustified. Once Bromfield and Ada were under way, the layoffs were inevitable. They might have been less severe if things had gone better, but they still would have happened. The critical decisions had been made years before, by Dan and company. Or perhaps a better way of phrasing it is that the critical decisions made themselves. How could the company have turned down either Ada or Bromfield? Turning down Ada would have cut off the whole of DoD as a market, and it would have been a severe insult to the already injured pride of the DoD compiler group. Bromfield had a dual attraction. From Bruce's point of view (he was the prime mover), Bromfield was the perfect opportunity to write the Compiler of the Future -- a customer with an incredibly ambitious goal, and willing to pay essentially unlimited sums to attain it. From the company's point of view, the contract was a guaranteed money-maker, and a chance to establish relations with the richest company in the world. The founders were searching desperately for someone to buy them out, and Mr. Bromfield seemed like a prime candidate.

The layoffs had very complicated effects. They finally laid to rest the last vestiges of the old spirit -- the unconditional loyalty to Intermetrics and to the group. Unconditional loyalty works in both directions or not at all. At the same time, the layoffs and the voluntary exodus that accompanied them laid the groundwork for the renaissance. The group was finally cut down to a manageable size, and although many of the best people left, so did almost all of the worst people. The net effect was a more homogeneous and, on the whole, a more competent group. The breakneck shrinkage was devastating, but not as disruptive as the breakneck growth had been.

We managed the transition from a small group to a large one exceptionally poorly. But there was no way we could have stayed small forever. The pressures to grow and make more money could not possibly be resisted. More subtly, we needed to grow for our own health. Considering the extremely low rate of attrition, we had to grow or stagnate. In fact, we did stagnate a bit in the years of slow growth. Always seeing the same faces, always doing the same work, always stuck in the same spot in the unwritten hierarchy.

Many things conspired against us. Dan's style was exceptionally well suited to a small, elite group and exceptionally poorly suited to a large, conventional group. Both Dan and the rest of us were unwilling and unable to change our ways. It was bad luck that we reached our critical point just as the industry entered its boom phase; the opportunities for catastrophic growth were irresistible. And it was also bad luck, although not entirely accidental, that the whole company experienced an epidemic of greed, unrealistic expectations, and self delusion at just this point.

The renaissance actually started before the layoffs, even before Bromfield was canceled. The underlying problem was management and our attitudes towards management. Under Dan, we were used to managing ourselves, and we resented it fiercely when anyone would try to impose order from above. This worked fine in the era of three or four person projects. And remember that those three or four people, working sixty hours a week at peak efficiency, could achieve as much as a conventional ten-person project. But when we started to take on genuinely large jobs like Bromfield and Ada, and when people were no longer willing to throw themselves into the fire, we could not survive without a more formal arrangement. Eventually, even the most pig-headed (like me) could see this.

A managerial class slowly started to form. It was a long, hard process. Most of the people who thought they wanted to be managers had no idea what the job was about, and were completely incapable of doing it. Several of the best managers were the ones who had resented management most fiercely, and who had never evinced the slightest desire to be managers until circumstances forced them into it.

If any single person deserves the credit, it is Dennis Struble. Coming as an outsider into a difficult and hostile environment, he managed to win universal respect. It was he, more than anyone else, who finally convinced people that the function of management was not to make everyone jump through hoops, but to help them with their jobs and to make their lives easier. Of course, this assumes a special breed of manager; most managers in the United States probably still think that they are supposed to make people jump through hoops like performing seals.

Ada finally came to a successful conclusion, and although the monetary cost may have been ruinous, the technical satisfaction was essential to our survival. After all that pain and grief, the Ada compiler turned out to be a pretty impressive product, even if it is still cursed with the original implementor's reckless disdain for efficiency.

Whatever the vicissitudes of sales and marketing, SPD's technical staff never lost their moorings; they retained a standard of pride and excellence from first to last.

The Delco project rediscovered the strengths of the original HAL project, but in a more refined form. Once again we had a serious customer with a huge problem which matched our skills perfectly -- a customer we could really help, and one who would appreciate our efforts.

Software is a very unusual industry. You can run an assembly line with a whip, although American managers are belatedly realizing that there are better ways. But software requires the close coordination and cooperation of many people, something that can only be nurtured, not forced into being. Formal devices and management tricks can aid or impair it, but the impetus must come from within. The collective mind and will of the technical staff is the essence; it eclipses all other considerations.

If management strays too far from the will of the workers, tries to shape it into something that it is not, the only possible outcomes are chaos or outright rebellion. Managers can have their own private goals -- to make money, to become more powerful, to move into new markets, whatever -- but they must always be subordinated to or cast in the shape of the unspoken goals of the technical staff.

The collective will develops diseases of its own. We, too, have our private reasons for working: to earn a living, to advance our careers, to become rich or famous, to innovate. But when it comes down to the daily grind, our goal must be to get the job done and to help our fellow workers get the job done. When we neglect this, the loftier goals cannot possibly be achieved.

There are still some serious problems, but we seem to have recovered our spirit in a new form. Gone are the days of fanatical loyalty, of anarchy, the joys and the pains of achieving the impossible. Things are less frenetic, less exciting and much less stressful. We go about our work methodically. And, miracle of miracles, we are able to do it just as well as we ever did in the old days, or maybe better, even if it takes a little longer and requires a few more bodies.

Throughout all of it, through the good and the bad, something fundamental and precious survived. Just barely, hanging on by a thread, but ready to grow again when the conditions were right. It is hard to say just what it is: maybe a pride in our work, ourselves and each other, maybe an open-hearted attitude and an eagerness to help. We all love to grumble, but most of us admit, if pressed, that the compiler group is a great place to work. Dan's spirit lives on.