Really interesting to read about the history of the industry, but also depressing to see all the same bullshit (schedule-chicken, resource battles, etc) that hasn't changed in 30 years.
What's fascinating is that the book documents the rise of a computer but written in the 80's. The story is a bit technically detailed, one has to have the background in computing to enjoy it.
A very nice story of how a small team of engineers works to create a new computer for Data General in the late 1970s. The computer is not particularly groundbreaking, a new 32-bit computer that is software-compatible with the old 16-bit model. But the story is remarkable for its insights into how the work got done. It explains the characters, their motivations, some technical details (at just the right detail)—and is filled with memorable and realistic anecdotes. It is well paced, well written and well organized, a very nice piece of sociology.
I borrowed this, from the library, a couple months back. It sat and collected dust; I had too much going on, at the time, to spend much time reading.
This time, I cracked the book and knocked it out in less than a week (including a couple days where I didn't have time for reading).
The book won a Pulitzer. The writing shows, clearly, why. It's the definition of "engaging." The author has knack for describing people, not just in appearance but in manner.
The book is, ostensibly, a tale about the creation of a new model of computer. Data General needs a new, 32-bit computer to compete with DEC's 32-bit VAX. The senior management of the company builds a super team of engineers at their new location (in the Research Triangle in North Carolina). A particular manager (Tom West), back at their Massachusetts headquarters, decides that effort isn't going to get it done so he recruits a team of engineers, convinces management to hire many more (straight out of college), and inspires, cajoles, manipulates, etc. the MA team to pull off a a miracle: a 32-bit machine, competitive with the VAX (keeping Data General profitable) but also backwards-compatible with their prior, 16-bit machine. For existing customers, they can bring their existing apps and data to the new machine, then start migrating to faster, more-capable 32-bit computing. The VAX was not compatible with any prior model so anyone buying that machine was starting over on applications.
The engineers work hideous schedules, in a basement engineering office, and make it happen. Mushroom management ("keep 'em in the dark, feed 'em s**t, watch 'em grow") and pinball management (if you win, you get to play again) are major factors in this.
When it's all said and done, many of the lower-tier engineers thought West had done basically nothing. Hate to say it but ... how management behaves has a lot to do with how successful a team will be. Some of the upper-tier engineers / lower-tier management knew quite well what role he played. And some of them, after the fact, looking at how the machine would be packaged and configured, were blown away when they realized all the "background" stuff he'd done. Many of them went on to work on other projects which West and started planning before this machine was done.
Tom West wasn't the only one of the group to lose a significant amount of weight over the "sprint" to get the machine done. At least a couple engineers burned out and went looking elsewhere for work.
I am not an electrical (hardware) engineer. I'm a software engineer. Though I work in a different discipline, there is a LOT of overlap between what they did and what I do. When starting a project, I also have to map out the architecture of the whole thing. These tasks will be done by this part, those tasks by that part, etc. Then you develop one piece. You test that piece, using as much automation as possible, and you keep (unit) testing until it works. Then you develop the next piece and test it into submission. Then you put those pieces together and (integration) test the combination into submission. Keep iterating this pattern until the entire project is developed, tested and works.
If you develop too much, without testing along the way, and reserve your testing for the end, you may never get it working. That's the mark of an amateur engineer, whether hardware or software.
Engineering is all about managing complexity. The best way to manage it is in pieces, as you go, integrating pieces together ONLY when you know they work in isolation.
And, of course, hoping that the stakeholders don't change their minds, and the project requirements, along the way (ask me how I know :-)
While the book never uses the term "flow state," many of these engineers get into a "groove," whether designing, building or testing something and ... next thing you know, it's 2 am. Where did the rest of the day go? What is my SO going to think of me getting home so late? Oh, crap, I gotta be back in the office again in 6 hours and I still need to go home, get some sleep, etc.
I discovered, in 1981 (my freshman year of high school), that I could get into a flow state while writing programs. My high school had a handful of Apple II+ computers and, because the computer teacher trusted me, I could get into the computer room (usually solo) for the last hour of classes each day. I'd get in there about 1:45 pm, sit down at a computer, pull out my cheap FM walkman and get into it. Next thing I'd know ... it's 8 pm and I still need to walk home from school. Good thing the janitor could lock up behind me.
So, while I don't get into a flow state / groove working on hardware, I definitely have the same type of mindset as these engineers.
Note: if the term "flow state" is new you to, go dig into it. The difference between people who are working a job, and people who are doing what they love, has a lot to do with being able to get into a flow state.
To be clear: this book is set in the late 1970s. Their computer hit the market in April 1980. Some of the references in here are kinda dated. But, if you can look past that, and you either are an engineer (of some kind), are pondering becoming an engineer or trying to understand such folk, this book is well worth your time.
I really expected to love this book when it opened with an intriguing, excitingly written little anecdote. Unfortunately, what followed never reached the allegorical or dramatic heights of those first few pages.
The Soul of a New Machine is an account of the engineering of a minicomputer in the early 80s. It follows a smallish team, and along the way, attempts to explain the pertinent technology and make grander points about the industry and computers in general. It never quite aces any of these points. The team's story is just not that interesting; the technology isn't particularly illuminated (I struggled to understand it or even care, and I'm a computer professional); and the big picture is unfortunate because this particular book was written at a largely uninteresting time in the history of computers. Just a few years later, personal computers would cause a revolution that would make Data General's products and struggles seem about as epic as buying soda at the store. It's a bit like covering the mobile phone revolution by embedding with Sony Ericsson in 2006.
Kidder is a great writer; for the most part, he keeps this dry tale readable, and does his best to make it somewhat entertaining. But he can only do so much with a yawner of a subject. The quotes he's given ramble and fizz out ("From the start it was a very important project", "We're building what I thought we could get away with"). A typical anecdote here is the engineering team asking to have business cards printed out, and their lieutenant coming out of the boss' office with a simple "no". Not exactly the stuff of folklore.
If only Kidder had instead been embedded with Apple, Microsoft, or Xerox. As it is, I'm not sure I'd recommend this book since the few bits of insight and the-more-things-change moments aren't worth the dull rest of it.
Replace hardware with software and you get a description of how some of the most ambitious initiatives today feel like. Passion is a double edged sword. The ultimate bear trap is the one that catches your sense of self. Extraordinary outcomes require extraordinary efforts and this is why the whole conversation about work/life doesn't make sense when goals are way out of the ordinary. Overall a good history lesson. Mixed feelings at the end.
"The computer revolution brought with it new methods of getting work done—just look at today's news for reports of hard-driven, highly-motivated young software and online commerce developers who sacrifice evenings and weekends to meet impossible deadlines. Tracy Kidder got a preview of this world in the late 1970s when he observed the engineers of Data General design and build a new 32-bit minicomputer in just one year. His thoughtful, prescient book, The Soul of a New Machine, tells stories of 35-year-old "veteran" engineers hiring recent college graduates and encouraging them to work harder and faster on complex and difficult projects, exploiting the youngsters' ignorance of normal scheduling processes while engendering a new kind of work ethic.
These days, we are used to the "total commitment" philosophy of managing technical creation, but Kidder was surprised and even a little alarmed at the obsessions and compulsions he found. From in-house political struggles to workers being permitted to tease management to marathon 24-hour work sessions, The Soul of a New Machine explores concepts that already seem familiar, even old-hat, less than 20 years later. Kidder plainly admires his subjects; while he admits to hopeless confusion about their work, he finds their dedication heroic. The reader wonders, though, what will become of it all, now and in the future. —Rob Lightner"
The last email for the day is sent. There are no more calls tonight. And you settle in, warming your bones beside the proverbial fire. Music now fills the room.
The thrill is gone
The thrill is gone away
As you take comfort in the king of blues, you reflect on your work, once your passion.
After many years as a software engineer, one day you find that have ended up with a 'job'. Its hard to pin point when the fun went out of building things. If you find yourself agreeing to BB King, it would be a good time to pick up this book.
Tracy Kidder takes you along on the fascinating journey of this team of engineers as they build The Eagle at Data General. The scene is familiar. An aggressive and brash company - a bastard in the world of IBMs. A young team set up with an impossible deadline, and oh did someone mention the survival of the company depends on the team delivering on time.
The book is more that long hours and the sweat and grit. Kidder introduces you to the engineers, each unique in their on way and also so familair to someone you know from work. The book anchors around Tom West, the man of conviction, man of action. He's the phantom, the jesus reincarnated as bobcat. Nobody knows what he does, but at the end, when you look back you see his magic. The glue that binds all of it together.
"Not everything worth doing is worth doing well", says West. Of late, I am convinced that to build a great product, more than skill you need conviction that you can build a great project.
Data General is a place where Mushroom Management is thriving (keep them in the dark, feed them bullshit). But you encounter some very real people in this book. You encounter the passion, the reason why builders build! I loved this book for that.
"Look, I don't have to get official recognition for anything I do. Ninety-eight percent of the thrill comes from knowing that the thing you designed works, and works almost the way you expected it would. If that happens, part of you is in that machine."
At the end, it all comes down to a game of Pinball, says West. You win, you get to play again. You ship, you get to build again. That is what the people are in for. Thats the reason why we build. There are no morals, you take away what you want to. (There is plenty of wisdom though).
I cant believe the book is as old as me. The team, the suitation, the people are still relevant. If you replace MUD with Quake2, this book could pass off for my generation. Maybe it can pass of the current generation too.
The book took me down the memory lane, the good old days when coding was fun. When you lived by the motto "I did it for the kicks". Maybe its the nostalgia speaking, but everything looks better in old photographs. The book has been a great reminder for me, holding a mirror and asking "are you having fun?"
PS: This year 2000 article O, Engineers! that tracks down the engineers after 18 years of the Soul makes a fascinating after-read.
A fun story about the engineering behind a new computer. It's got some good moments, but relies too much on telling us what beards people wear and what they were like as children. Maybe it's mentioned in the prologue, but I didn't realize this book was written by some guy who was just paid to follow the progress of the engineering --- it really detracts from the story, since it becomes evident that this book wasn't written due to the historic impact of the thing they were building. No, they just happened to have a journalist around.
All in all, you probably know already whether or not you're going to read this book.
The Soul of a New Machine recounts the story of the massive engineering efforts that went into the development of the Data General Eclipse 32-bit computer.
You can tell that Kidder is a story teller and not a computer engineer. The most interesting parts, to me, were the description of the computer architecture and design decisions made throughout the project, but these are few and far between. Kidder's focus is primarily on the people of the project, and the hardships they endured to make this computer a reality.
I would have also liked to have seen the impact of the work done here. Very few people have heard of Data General. What happened to the company? Did the Eclipse steer the industry in a new direction?