I can't believe this is not required reading for a computer architecture course!

In my high school Biology, H.G. Wells' The Time Machine was assigned to be read over the winter vacation. It was a bit of a stretch, but did make the class a bit more interesting. As I read Kidder describe the toil undertaken in creating this new computer - working under the pressure on the brink of insanity to find those incessant bugs - I thought this the perfect companion for the CS154B Computer Architecture class at UC Davis. As students, we worked on analogous type of problems and under similar conditions: this book provides a human angle to that struggle. If I recall correctly, pipelining is explained so well, I bet my grandma would even understand it! And yet there are plenty of subtle technical details buried in this masterfully written true story.

As a shameless Tracy Kidder fan, I found this book quite extraordinary. Written in 1981, it chronicles the building of a 32-bit microcomputer at Data General. This was a time when the competitive environment for computer advancement was heating up to a furious pace. Today, these times read like ancient history, exceptt for the fact that it was the dawning of an age.

Tracy Kidder, a journalist, not a computer engineer, took on the task of capturing the new computer building process when it was part science, part art, and to some extent part magic. His Pulitzer Prize winning book puts lightning in a bottle. What we see is what builder-engineering is about, how the lure of building a new machine becomes a drug, how the challenge of problems (design, debugging)take over the engineer's life, and how managers must manage with both a strong hand and a loose grip simultaneously.

The mental and emotional stress that becomes the engineer's life, the almost fraternity-like antics that take place to lessen that stress, and the demands of producing a functioning and profitable machine dominate the realities described in the book. We read about the vision for the new machine, the challenges of getting upper management to fund what they don't think can be done, the excruciating deadlines that must be met, the overwhelming frustrations during break-fix times, and the idiosyncrasies of the players.

I was left in awe of the process, both technical and managerial, and inspired by the creative spirit of professionals who are willing to invest their souls into their creations, no matter what.

With Kidder’s dab hand at fleshing out the wide cast of “characters” in just a few paragraphs, this book makes for a livelier portrait of the personal computing boom than you might expect going in.

For the modern reader, the detailed descriptions of the now-outdated technical specs of these the-new machines occasionally dragged. The exploration of the foundational culture of an an ascendent tech sector remained engaging and relevant, however, living as we all are in the world shaped by those foundations.

I really liked this. I learned a lot about DEC and engineering processes within a high tech company. I had first listened to n   Housen by  Tracy Kidder; I liked his style and wanted more, so I read this. I would still like to read more, but it's hard to find his stuff in online libraries these days.

I read this back when it was current, and I was programming at the time on a Data General MV6000, so it was really fascinating to me how that series was made. I enjoyed the book immensely, and found it a fun read, a page turner. It was nice that Tracy seemed to learn enough about the whole process, the technology and the project, that he really understood what was going on. I think a lot of journalist types wouldn't have managed that. They would have made a lot of vague statements in their books talking about technical things with not enough detail for you to figure out what they were trying to say, and that would have been maddening. Tracy seems to grasp fully subjects like science, technology, and medicine, so he's wonderful to read on these subjects.

Tracy Kidder put together a wonderfully rich and in-depth look at the inner workings of a team of designers working on a new minicomputer. With scarce resources, minimal corporate support, and little but what they could scrounge and their own intellectual prowess and determination, the team succeeded against all odds. And with Kidder's able help, we are right there with them. We see the manipulations, the generation of fierce commitment in the experienced and newbie alike, and the almost fanatical devotion to cause that was the beginning of a new movement and new expectations for employee commitment. Kidder wondered with some anxiety what it would lead to; with the advantage of more than two and a half decades, we can see the results.

Some comments in lieu of a review:

Anyone interested in the characters presented in this remarkable, Pulitzer-winning book by Tracy Kidder should consider reading a follow-up published by Wired in 2000…

Some more recent readers appear to have found the book "dated" in one way or another, a historical relic of the late 1970s. Granted, the products of computer technology have vastly changed. But the processes by which computer technology is developed may not have changed so much, if at all, and in any case have probably varied with time and context. Anyone lucky enough to get a job with Google nowadays won't find much in this book to remind them of work, but some smaller and/or hungrier companies still operated this way in the 90s, when I worked at a few, and surely some still do…

This work, written about four decades ago, tells the true tale of how a team of computer engineers built a new computer. In an era contemporaneous to Apple Computer’s founding, Data General computers built affordable new computers for the masses. A group of engineers built a new circuit board that eventually pushed itself to the forefront of the market.

This book is about engineers and the culture of engineering more than anything else. It’s about smart young men who pour their lives into projects in order to see them succeed. It’s about their lack of social skill, their strange coping mechanisms, and their bonds of brotherhood and friendship. Such displays are familiar to anyone who has spent much time around engineers. In Kidder’s telling, these engineers give this product supreme meaning for a couple years of their life.

Kidder’s journalistic act won a Pulitzer Prize. It’s amazing how he transforms mundane engineering practices into a fast-paced drama. His ability to empathize with average engineers (especially as a non-engineer) confounds me. He describes this scene as exciting for the masses when most non-engineers would consider such adventures as boring. This work still interesting to read almost forty years later.

So what is the soul of a computer? To Kidder, it’s about working hard on a project to which one has given supreme importance. It’s about a team coming together despite their social hang-ups. It’s about pushing a product out only to have marketers and business-people claim its inventive force as their own. It’s about not just the circuit boards and software but the people who create the computer for us.

There are many, many project management books that purport to reveal the ultimate system for surmounting the myriad challenges to releasing a product on-time, in-budget, and with all the promised features. It's a popular and useful genre, even if much of the material is just reshuffled and rebranded old bromides, but sometimes the most helpful and memorable way to offer project management advice is to just pick a single case study and dive in deep to explore the group dynamics that result - or don't - in a successful product. I'd previously read Mountains Beyond Mountains, Kidder's excellent profile of Dr. Paul Farmer, and this much earlier work, which won him a Pulitzer, is just as detailed, thoughtful, and revealing. It's about the race from 1978 to 1980 by one team of computer engineers at Data General to develop and release a 32-bit "minicomputer" (one of the many charmingly antiquated terms that will give those who know their industry history a smile) called the Eclipse in competition with another, more-prestigious team that's been given a more glamorous project in a shiny new office, with the fate of the company looming in the background. Heroes and villains are the keys to great drama, and so as the narrative follows the protagonists, who are working on "Eagle", a 32-bit extension of the existing 16-bit line of computer hardware instead of the brand-new computer of their dreams that they imagine their counterparts are gleefully assembling, their struggles to design, build, test, debug, and actually finish a computer without more hacks, kludges, and shortcuts than are absolutely unavoidable in such a short time take on a mythic glow that anyone working on a big project in the tech industry under a tight deadline will immediately recognize, despite the passage of nearly 40 years.

If I had to pick a single part of the book that best-represents why the book would make a worthy addition to a computer engineering syllabus, it would be the chapter "The Case of the Missing NAND Gate". It's an almost self-contained episode towards the end of the book, where, late in the development cycle, several engineers are attempting to debug an erratic logic failure, which occurs just often enough to be indicative of a real problem but not so often as to be easily reproducible. Kidder relays the team's efforts to determine if this diagnostic failure is at root a software or a hardware issue, with an amusing layer of "antagonistic camaraderie" on top of their troubleshooting, as all of them had a hand in designing the machine and each wants to solve the problem but none wants to have the root cause bear their fingerprints. This was back in the era when computer design involved the frequent use of oscilloscopes and it was often a genuine question if chips on a board weren't properly spaced for optimal signal timing, so fans of vintage computing will really enjoy as Kidder walks the reader through the finer points of system caches, assembly microcode, page faults, and logic gates while various engineers, working in shifts, propose and reject theories to explain the anomaly. It's a genuine puzzle, and Kidder does a great job explaining just what the problem is and why it's so difficult to diagnose and eventually solve, translating the arcane technical details of the fault with the various components of the system architecture until it's not just lucid but even enthralling. Here's his rendition of one potential explanation from one engineer named Guyer:

"The diagnostic program originally puts the target instruction at address 21765, and then, sometime later on, it moves the target instruction to 21766. But the IP never gets word of the change, though the System Cache does. Now, sometime after the target instruction is switched from mailbox 21765 to 21766, the program directs Gollum to execute the instruction at 21766. The IP receives this command and looks through its cache. It says to itself, in effect, 'Mailbox 21766? I've got that address and there's an instruction in it. Let's run it.' But in the I-cache, the target instruction is still at 21765, and mailbox number 21766 contains an error message. In short, the I-cache contains an outdated piece of memory. Why didn't it get updated along with the other parts of the memory system? Maybe, Guyer writes, the System Cache is to blame. The System Cache is supposed to know exactly what is in the I-cache. If an instruction or data gets moved to a new address, the System Cache is supposed to tell the IP to throw away the outdated mailbox and get the new one, the one with the target instruction in it. Somewhere back in the program, Guyer figures, the System Cache lost track of what was in the I-cache. It forgot that the IP had the target instruction in mailbox 21765, and so, when the change was made in the location of the target instruction, it never told the IP to get rid of the old, outdated mailbox. Guyer likes this hypothesis. He records it with mounting enthusiasm; and describing it later, he repossesses the feeling, speaking rapidly, gesturing with both hands. Then he stops, puts his hands on the table, and says, 'Of course, it was completely wrong.'"

The book is also notable for broader reasons. Massachusetts was a much larger center of the technology industry in the 1970s and 80s than it is today, and the "Route 128" cluster competed directly with Silicon Valley for talent and prestige. However, the Eclipse team's main antagonists were not in California but in North Carolina, giving the modern reader a glimpse of the "flight to the Sunbelt" in embryo that has helped the Research Triangle, among other places, at Massachusetts' relative expense. Data General was founded by former employees of Digital Equipment Corporation; I've read articles arguing that Massachusetts' relatively strict enforcement of noncompete agreements was a major force that drove tech firms to less strict jurisdictions, but that doesn't seem to have been as large an issue here as the typical lure of lower taxes. However, prospective MBAs should scrutinize closely the decision by corporate management to have two different teams working on overlapping products, as ultimately the highly-regarded North Carolina team working on the prestigious brand-new 32-bit machine (dubbed "the Fountainhead Project", with hilarious irony) was upstaged by the "Eagle" team, whose less-ambitious 32-bit extension of the 16-bit Eclipse became a huge moneymaker for the company. Now, hindsight is 20/20, and it's obviously impossible to consistently tell ex ante if internal competition, which is often positive, will in the end have wasted resources. After all, the Eagle team did produce an extremely successful product, although we don't know how much was spent on the Fountainhead team. But lack of clear focus is always risky, and corporate politics can have damaging downstream effects on teams of even very smart people.

But any look into the subtleties of nerd psychology has to account for the fact that the drive to create cool technology is often far more powerful than any corporate folly, even and perhaps especially if that involves extremely long hours of hard work. Occasionally the concept of "mushroom management" is invoked, which turns out to mean "put 'em in the dark, feed 'em shit, and watch 'em grow", and one paradoxical upside of not being the top brass' favorite project is that, with protective leadership, that can actually mean more opportunity to produce. There's an interesting detail in the life story of Tom West, the top manager for the Eagle project: "He went to Amherst College, in western Massachusetts, where he studied the natural sciences. He did so without academic distinction, and it happened that Amherst was just then embracing a new Calvinist fad called the underachiever program: young men whose brains seemed much better than their grades were expelled for a year, so that they might improve their characters. At Amherst, certainly, and possibly in the entire nation, West became the first officially branded underachiever. It was something he'd always remember." This story takes place after the end of the naive cyberhippie movement of the Whole Earth Catalog/"All watched over by machines of loving grace" era, so that technoromance had been firmly replaced by a more modern engineering sensibility, but there's still poignancy of the ceremony at the end of the project, where the team members come to grips with how much of themselves they've put into what would be released as the Data General Eclipse MV/8000, elevates what could have been just an unusually lengthy product diary into an account of creation that justly deserved its Pulitzer. One of the engineers had a typical complaint:

"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.'"

Maybe, but the reason why his project shipped and his rival's didn't wasn't because he had superior consultants from Harvard. As Kidder recounts from attending a trade conference: "It seemed to me that computers have been used in ways that are salutary, in ways that are dangerous, banal and cruel, and in ways that seem harmless if a little silly. But what fun making them can be!"

This is the 2nd time I've read this book and it took on a new meaning after being part of a huge AWS product launch. The feeling of camaraderie, pride, and purpose was something that I had just recently experienced which made me relate to the engineers and managers in a different way.

I loved it the first time I read it but somehow was able to love it more. At the time I didn't understand the historical context accurately. I've recently been reading about the timeline of computers which was a big help. Knowing this was in the late 70s is important because this was the rise of the personal computer and the slow death of the minicomputer.

I think it is easy to overlook this book and not understand it for what it was at the time. Computers were still foreign and not many people owned them. They were in lots of workplaces but not everyone had access to them.

This book won a Pulitzer which was surprising to me before I had read it. It was hard to believe a book about a bunch of nerds building a computer would win the prestigious award but you quickly understand how it did this after the preface of the book. Kidder starts the story by introducing the main character, Tom West, an enigmatic man on a boat off the East Coast with a group of strangers as they sail the sea. It expertly foreshadows West's character and his role as the general manager of the computer the book documents. Without ever mentioning a computer you start to wonder if you picked up the wrong book.

I wish another company would open its doors to a skilled storyteller like Kidder. Chronicling a software startup or the creation of a large service at a big company in the same way would be a riveting read given the advancement of tech.

I really recommend this book and consider it one of my favorites. Kidder is an expert at his craft and seamlessly blends the team's stories into the story of the company, Data General, and that into the overarching story of the industry.

Hold on to your hats, kids! We're taking a trip back to the late 70s, where there were more than 2 or 3 types of computer to choose between, but they cost half a million dollars and were the size of refrigerators. This book relates the development of a new computer at Data General, a highly successful manufacturer of the time, though forgotten today.

This is really one of those plus ça change, plus c'est la même chose things. While it is so much of its era - maybe the bronze age of the computer industry - so many things have barely changed. Seeing which things are identical and which are unrecognizable is one of the fascinating things about this extremely interesting book.

Having worked in the broad field of computing for 15 years, the processes of developing and delivering a technical project were at the same time familiar and alien to me. The speccing, creating, iterating, integrating, debugging are described very convincingly and were very recognizable. But the way those things were achieved - the equipment used, the amount of documentation, the way issues were tracked - was all very different to practices today (and for good reasons at the time). I would have enjoyed a bit more technical detail, but then I imagine that I'm a bit more technically proficient than the target audience.

The characters of the engineers, their goals, and the counter-intuitively dysfunctional ways of getting the most out of them is remarkably similar to what one might encounter in the field of computing today (to be honest, I'm only familiar with development on the software side, but I assume the same broadly hold true on the hardware side). This project tended to use much younger engineers than standard in the industry, and motivated them by giving them a high level of responsibility for their particular areas - which meant they felt that they had to work ridiculous hours. This was good for those involved, but also meant that the creation of the machine was much cheaper than it would have been with more experienced people working regular hours (that said, it also came with a higher risk of failure).

Additionally, the office politics of a large tech company are well depicted, and should be instantly recognisable to anyone who's ever worked in such an organisation.

The story of the creation of the machine has some strong parallels with Revolution in the Valley - about the develpoment of the first Mac (remarkably only about 5 years later). In both, the computer was thought of (at most) secondary importance within the companies building them. And both had a team of highly-motivated, young engineers driving them forward, with ridiculous workloads, and thriving on their "outsider" status. Data General's computer was not revolutionary like Apple's, but that is not really what this book is about. It is a fascinating insight into the inner workings of the computer industry - a field which affects all our lives and yet is somewhat opaque. It is remarkable both as a historical account, and also for how relevant it is today.

In the early 1980's when this book was first published, the author had to communicate the complexity and labors experienced by a group of engineers as they developed the next big thing for a second rate company. Most of those who read this book today have a level of computer literacy that may be beyond what the author's computer literacy was when he wrote the book. Consequently there are sections where the author takes great care to convey computer concepts and operations to a reader who has never seen a computer. The modern reader might find such sections quaint or boring, while a few others, who had lived through those times will find the detail and care a nostalgic visit to past lives. Bear with the author as he describes the ins and outs of Adventure and intricacies of machines that have become dinosaurs in the pantheon of technology.

As so many other reviewers have mentioned, the highlight of the book is the team and interpersonal dynamics--human drama that can be found in pressure cooker development environments today. This portion of the book is as relevant and insightful as it was in 1981.

The one message that has stuck with me several weeks after having read the book is "Pinball is what counted". The rule of pinball is that if you win, you get to play again. "You win one game, you get to play another." Playing the game is a powerful motivator for a select few individuals. Many readers may find it difficult to understand why the team took on such a challenge, but there are a few who will recognize the thrill of pinball and understand the siren song of working in difficult environments on challenges that might be near impossible to achieve.