I really enjoyed 'The Soul of a New Machine' as a work of art.
But....
Having worked in semiconductors and software, I can't help but wonder if life imitated art or art imitated life.
The grind and machismo around it rang so true to me, but I also disliked how it glorified something that I felt was pretty dysfunctional. I love creating things, but not everything has to be a death march, and surviving it isn't necessarily some badge of honor.
While I see the glory in the engineers rising to the occasion, I also see that the management of that company was clearly to blame for the awful situation in the first place. With that type of management, it's no wonder Data General isn't around any more.
Anyway, I would highly recommend reading 'The Soul of a New Machine'. Just don't take it as an instruction manual on how to run a tech business.
It's an excellent, nearly perfect instruction manual on how to run a tech business -- in the situation and time that tech business was in.
For context, DG was about to go obsolete, but Tom (and others) recognized this where almost nobody else would've, and managed to transform the company from a mainframe company to a minicomputer company, with a small, ragtag team of dedicated engineers, without a map or prior art, and with desultory support from the checked-out, incompetent C-suite.
Tom's idiosyncratic, no-nonsense style wasn't for everyone, but I can think of very few tech leaders who could have succeeded as a manager in that situation.
Source: worked directly for Tom at Data General for several years.
For another view of DG & Tom: I interviewed Dick Sonderegger [1] who also worked there and knew most of the people. He said they generally had a low opinion of Kidder and thought he'd believe anything you told him.
That said, it IS still a great book, and given that Kidder's not an engineer, he did an amazing job.
The "he didn't know anything, we coulda told him anything and he woulda bought it" line, which Sonderegger relayed from the DG guys, speaks more poorly of the DG guys than anyone else. I mean, if what a dummy he was for believing us is their critique of the work... that's gross, right?
Maybe I'm missing some crucial context or something.
"what a dummy he was for believing us" -- I don't know if that's really what they thought. Maybe it was more like "he didn't try to verify anything, ask any hard questions, or get any context on it." It's been too long since I've read the book.
Did you like the bit about him telling the Marines, "I want to be a close air support pilot in 'Nam!"
And they said, "No, you're going to be a computer programmer!"
It goes counter to the folklore that they ignore your background and just hand you a rifle.
I've heard the story of new recruits and their assignments told a few different ways over the years. My grandfather credited his ability to touch type with keeping him out of combat, and it's certainly possible that whoever made that decision also noticed a few other qualities that made him suitable for working in an office. On the other hand, I know a guy who was drafted in the Vietnam era after getting a BS in Physics and Astronomy and the Army's best use for him was... combat.
I don't even know the name of the position of the guy who decides where draftees are sent after basic training, but I expect that as with so many other things, some of them are a lot better at their jobs than others. And perhaps the Marines do a better job of it than the Army.
DG was never a mainframe company. west was trying to transform a small 16-bit mini into a 32-bit mini. De Castro, the CEO of DG at the time said he wanted that, but "no mode-bit", which shows him as being not being disconnected from his engineers. All in the book.
I'm curious about what various people think defines a mainframe. IBM people clearly have something in mind, and DEC people something else. Maybe DG had yet another definition.
A mainframe is a high-RAS (reliability, availability, serviceability), high-performance, high-cost, modular multiprocessor machine with specialized coprocessors; running a hypervisor-style operating system that is largely concerned with allocating resources and managing security partitions. Interconnections among modules happen at system bus latencies and bandwidths.
zabzonk is technically correct, which is the best kind of correct. I was using 'mainframe' colloquially and lazily. DG's mini line was used for the same kinds of things as mainframes, but they were formally minis at the time.
Thanks for sharing. I'm really fascinated by everything in DG. Actually I didn't know DG until now.
Is it possible for you to share a bit more? I'm sorry for being vague but I assume anything would be of interest of the HN public right now. If there is really a need for a topic, I couldn't help but Googled your name, looks like you are involved in a project called "Poppet", maybe it is possible to speak a bit about that one?
I also dotted-lined into Tom in the 90s when the big DG NUMA Unix servers were being developed. I was the product manager for the line--along with a bunch of other systems going back to the mid-80s a few years after the "Eagle" in the book was released.
I've shared this before but a really interesting internal publication from the mid-80s was A Year in Development with lots of interviews and photographs. https://archive.org/details/year-in-dev/mode/2up
Here is an advertising brochure for DG's first product, the Nova minicomputer, when it appeared in 1968. A weird mix of technical information and full-page close up photos of DG executives trying to look tough:
Interesting. I got the exact feeling -- From some pages I read hardcore assembler instructions, but from others I saw someone that looks like a mafia boss.
Must be interesting time though. I love those "Byte" and "Dr.Dobb" magazine ads in general. They are all very creative and sometimes do not shy away from "exotic" stuffs such as beautiful ladies and such. I wonder what sub-industry still has that kind of culture :)
Thanks for responding, and for 'disagreeing' so respectfully.
I feel honored to interact with one who was present.
I didn't mean to attack an individual, and my management comment was more general than just Tom. I saw Tom's actions as reactions to a bad situation.
My comment is more directed at the people I worked with who took the wrong message away from the SOTNM folklore. Being against the ropes and fighting for your survival at all costs isn't something to look forward to, and definitely not something to expect from employees.
You are right that just copy-and-pasting that pace and expectations onto other development teams is (a) commonplace and (b) not a great recipe for success. I don't think SOTNM valorizes that behavior itself, but it's definitely possible to read it the wrong way and think the grind and the deathmarch are necessary or useful parts of normal development activity. Your caution is valid.
Perhaps it is to computing what the Fountainhead is to architecture.
The feeling from the inside of a great moment or historical period
that encapsulates an idea(l) can't be told factually. The space race.
The Manhattan project. Cracking Enigma at Bletchley Park. We all read
those boks and watch the movies, and wish we had been inside those
moments. Reality was probably heat, dust, coffee, burned fingers with
soldering irons, paperwork, money arguments, getting cranky working
late hours... much the same as your ordinary workday.
Yep, even for military projects such as SAGE and Bombe, I'd say the a normal day is not too different from an engineer's normal day. After all we are all humans, and bureaucracy inevitably grows within all such large projects.
I'm not sure. I've been through some interesting ones. Some pioneering work on courseware for Apple II computers, one of the first Brazilian news portals, the third-gen Brazilian voting machines (the one with Windows CE - not my fault)... All these had the feeling that we were on to something big, not that we were writing history, but that history was writing itself, as if all we could do was to surf that huge wave. And surf them we did.
I understand the value of work-life balance, and I wouldn't compromise it on a normal day-to-day operation, but when you feel like you are doing something really great, it's almost like the art takes control and you need to chanel it into the world. That the thing you are building is begging to exist and you are the one who can deliver it.
OK, I guess it's going to be some shameless self-promotion, then, sorry:
I wrote a book (https://www.albertcory.io/inventing-the-future) that's set 7-10 years after TSOANM. Unlike Kidder, I was actually part of it. One of the reviews compares it to TSOANM, so I guess that's high praise.
Since there are already at least two non-fiction books about all that (Fumbling the Future and Dealers of Lightning) I wrote this like it was fiction, meaning with characters who get to do things and talk to each other, and don't know how it all turns out.
Nearly all the players who are still alive helped & critiqued it, and one (Dave Smith, the inventor of icons) wrote the Foreword.
Right?! Hi I'm Tom West's daughter, librarian, owner of MetaFilter and someone who spends a LOT of time talking to people (mainly men) who take only some of the messages away from that book. The book was great. I'm in it in a single sentence. My sister isn't in it at all. My parents divorced shortly after the book came out. My father had never "let" my mother have a job (it was a different time) and so she was ill-prepared for the single life, but made it work.
I hammered out a decent relationship with my dad despite the fact that he was basically married to his work, was probably somewhere on the autism spectrum, and had a problematic relationship with alcohol. He was a good guy but he learned interpersonal interactions somewhat by rote and in a business role where the goal was "results" he just did what he had to do. It's weird growing up when your dad's nickname is The Price of Darkness.
He wound up having a decent retirement after being a company man most of his life, got to sail a lot more, had a second messy divorce, and died in 2011. At his memorial service Tracy Kidder spoke eloquently about working with my dad through the writing of that book (he basically lived with us on weekends for a while) and how he knew the book had been good for him--he won a Pulitzer, was catapulted to some level of renown, got to write more books--but he was never quite sure it had been good for my dad. I also wonder sometimes.
So, yeah, when I talk to people who are reading it again or for the first time, I often ask them to reflect on what the book says about work/life balance, about gender norms (there's one woman in the entire coding team), about how project management should run, and about the weird cult of personality that can grow up around people who don't quite get along with people, and how things could be different.
Certainly true. Though I will say that a female engineering friend of mine--upon seeing A Year in Development (linked elsewhere on thread) created a few years later about, well, a year in development at DG--had the immediate reaction "Look at all the women!" But maybe that's more a statement about how things haven't gotten a lot better. (And many of the women, in my experience, were in project management and engineering-adjacent roles.)
Hi Jessamyn! I read Soul of a New Machine for the first time just 3 years ago, even though I’m old enough to remember seeing it in the computer section of my local library as a relatively new release. Before I read it, I saw a comment you made (on Bryan Cantrill’s blog perhaps?) similar to this one. I wanted to thank you for that, as it undoubtedly changed how I interpreted the book as I read it. It can be easy to romanticize the hard work and sacrifice portrayed in a book like that, without understanding the toll that sacrifice took on those around them.
So thank you for continuing to offer your perspective on your father and his work.
Thank you, Jessamyn, for providing your perspective. You did the same to me, privately, many years ago on MeFi and I haven't forgotten it.
I cast the same eye now on anything that romanticizes similar work, and I've even seen it in places that are somewhat unexpected. The movie Jiro Dreams of Sushi is a perfect example of this.
Thank you so much for sharing something so personal. I have a family myself, and as much as I love playing at being the hero at work, I always have to look around me and assess how my decisions affect those around me.
My wife "doesn't work" but does more work than I do. What I do professionally isn't possible without her.
Your comment just reaffirmed my priorities. Thank you.
Thanks for sharing your thoughts! I admit I was more into the technical details and had little thoughts towards WLB and other things. I'm probably bored about my life so these "grand things" do pull towards me. On the other side I have a family so I tend to put that over everything else (Maybe that's the source of boredom?) so these books provide the drug of "grand scheme + technology" which is really my thing :)
I'm glad that you maintained an OK relationship with Tom. It could be tough relationship.
I read it in college and it had a profound impact. I swore I'd avoid that kind of pressure cooker environment. For the most part of the 30+ years of my career, I have. I've maintained a good work/life balance. Made a good living, have great family. Thanks for posting - I would never have imagined having this dialog 30 years later.
Soul, Show Stopper!: The Breakneck Race to Create Windows NT and Masters of Doom are my three favorite "computer product development heroics" narratives and I think they all describe toxic workplaces by the standards of 2022 and employees who aren't monomaniacs.
In their defense, a compelling book is going to select for drama, and depict it as dramatically as possible. And in the latter two books, people signed onto a new crazy-intense team knowingly and many of them made bank. I'dve happily done that at some points in time. I feel sorriest for the folks who were already Data General employees at the start of Soul.
I imagine a death march to be something worse than that. In this case everyone shared the goal, it wasn't a made-up deadline forced on underlings by a clueless management. This management knew they could do it, and the team knew they could do it and had done it before. That's what they were there for; the thing they hoped to be able to do.
When I think of a death march, I think of an engineering task (usually a software program) with a known-impossible deadline, where the team pushes back on the deadline and is ignored. Necessary tools not provided, work hours monitored, rather than progress, etc.
Yeah, I agree, TSOANM isn't really about a death march.
I am abusing the term. I worked on some death marches with guys who saw themselves as Tom West though, which is probably why I chose that phrase.
A death march, to me, is a project that you know can't succeed but you are forced to go forward anyway.
I once had a boss hold the team at work until a piece of work was done (and it was 2am before it was clear it wasn't going to happen). That was just one day, but that project was a death march.
Rereading it as an adult (1st time at end of high school), I agree. In my wanderings I've found the link below which is a less polished, perhaps more true version of DG which makes me think it wouldn't have been so fun.
One of the secrecy things in that piece really resonated.
I was at an executive briefing with some major customer at the briefing center. We were a couple of days away from from some new product launch that was relevant to the briefing but were under orders not to say anything. Anyway, my--I think--manager's manager decided to sketch a few TBA things out on the whiteboard or blackboard anyway when Edson walked in to say hello. She very unobstrusively managed to erase what was on the board before Edson noticed.
Oh man the book both glorifies but also does a good job to me of making it all look crazy, not held together, just barely going, politically isolated.
That there was a cause, a mission was do much a product of the early times, when we just didn't know as much yet, weren't nearly as professional or well set yet. That's a little less apparent.
I read the book The Soul of a New Machine in 1982 when I was an undergraduate in India. I was so impressed that I became determined to get into software development as a career. Then I came to America for grad school and got a programming job on campus in a science lab and the first thing I saw in the computer room was a Data General MV8000. I was awestruck that I was seeing the actual machine described in the book. I still remember learning to program in C on that machine - many happy hours on weekends.
If folks are looking for another Tracy Kidder book, I'd recommend _House_. It's the story of building one house in Massachusetts in 1985 or so. Kidder goes into the life of the buyers and the builders, and the result is surprisingly compelling.
I know what you're thinking: why not _A Truck Full of Money_, Kidder's book about Paul English, the founder of Kayak? It's a fine read, but I found _House_ to be more contemplative and open up wider vistas (for me, at least).
Kidder is a great writer. I think people might enjoy _House_.
Or better yet (than Truck), check out "Mountains Beyond Mountains", about Paul Farmer's quest to defeat infectious disease where it's needed most and available least around the world.
Yes, reading that book made hearing about Farmer's recent death hit hard. Hopefully the system of clinics he set up in Haiti and elsewhere will survive long term after his death.
I have to say, I read quite a bit of that but got bored with it. Not that it's not a great story about important work, but at some point I felt like I'd read all I needed to.
I still mull over his comment about the role of "architect":
> Between 1830 and the Civil War, architects published scores of pattern and style books. At one point or another, most of those volumes argue that an architect offers the client protection from the builder. The case is often founded on social class, the architect being the client's ally by virtue of education and breeding. The argument plays upon the suspiciousness of clients about builders, a wariness that seems to have been around for so long that it probably deserves to be called natural.
I can't help but apply that class interpretation to the roles of "architect" and "developer" in a software project.
I enjoyed House which I read at the time I had just bought an old farmhouse. He's a very good writer although I have to admit that some of the topics he's chosen for books don't really make me want to dive in.
Back in the 80s I worked for a computer manufacturer in the Valley designing chips and doing all the other fun stuff involved with creating and bringing up a new machine. When people asked me what I did for a living I told them to read "The Soul of a New Machine" - that was my job. Kidder really captured exactly what it was like to create those beasts, with all the ups and downs of computer engineering in that era. Different coast, different (much bigger) computer, but the process was exactly the same. Perfect historical snapshot.
I read this long ago, prompted when my dad landed a job lecturing on the later MV/4000 and MV/6000 models.
He'd sometimes work late and we'd go on a short family trip to pick him up. He'd set us up at a terminal to play games, my first journey into colossal caves. What really blew my mind, and I think cemented my love of computers and computing, was space invaders - an arcade game! OK text based sprites, but still the same gameplay as the real arcade machines, just less noisy.
I'm going to find a copy and re-read it as I remember it being compelling and a page-turner.
I used the MV/8000 (what the machines were eventually called by DG marketing) for cross development of games when I was at Atari.
I was pleasantly surprised by the quality of the OS and tooling on the MV/8000. It had a very capable screen editor (definitely not Emacs class, but still quite usable) and its file system and command language were pretty decent. It felt like someone had mashed together VAX/VMS and Unix. Perhaps that sounds horrible, but it could have been far, far, worse.
I was impressed with the tooling as well. I worked at the University of Washington in Bio-engineering, and we collaborated with the Department of Radiology. They were building up the first PET scanner at UW, and the PI on my project was simulating mass transport and exchange in the tissues of the myocardium.
We all had a couple of MV/10000s, and I think four MV/4000s. Radiology ran AOS/VS, while we ran (first) MV/UX and later DG/UX.
I really admired the C compiler. It was a first class piece of work, in my view. I believe it was largely written by Michael Meissner.[1]
There was a lot of cross-pollination among the Massachusetts minicomputer companies and Data General would later have a very well-regarded flavor of Unix (DG/UX). There was an MV version but it didn't really come into its own until DG shifted its focus to systems based on 3rd party microprocessors--initially Motorola and later Intel.
>There was a lot of cross-pollination among the Massachusetts minicomputer companies
When would you say was the point that people in Route 128 realized that the Valley had definitively taken over as "the place" for tech, with Route 128 and everywhere else falling behind? Was it the minicomputer bust, or had the center of gravity definitively shifted west before then?
(For young people's benefit, well into the 1980s Silicon Valley was just one of multiple centers of the computer economy in the US. Route 128 around Boston was anchored by minicomputer companies like DEC and DG, supercomputer/AI outfits like Thinking Machines, and software companies like Lotus and Infocom. Texas had TI, Tandy, Compaq, and Dell. Westchester and upstate NY was IBM land. Minneapolis had Control Data, Cray, and Honeywell. Of the four most important PC companies of the mid-1970s, only Apple was founded in the SF Bay area; MITS was in New Mexico (which is why Microsoft was founded there), Commodore was in PA, and Tandy was in Fort Worth.)
I wonder how much of this was labor law in California. For instance, non-compete clauses are essentially forbidden in CA.
There were a ton of small companies in SV, and it was incredibly easy to interview, change jobs, and your commute would get shorter by a couple of blocks. (Though commuting in San Jose / Mountain View was pretty terrible).
That explains a lot about MV/OS (or whatever it was called). It definitely felt like they had Unix envy, and were trying for a fairly nice environment for writing software.
AOS/VS. I don't know the whole Unix history at DG and I came in a bit later. But even when I joined in the mid-80s, I'm pretty sure there was a somewhat skunkworks Unix contingent (with both DG/UX and a hosted on AOS/VS MV/UX variant) which I'm pretty sure were running on MVs at the time. Not sure if the Unix folks were down in RTP in NC by then but there were definitely Unix fans among the OS group(s). DG didn't push Unix until later--it was just one of the things we offered--but I think there was probably more overt hostility from Ken Olsen at DEC.
(And I'm not sure Edson wouldn't have at least tacitly supported something at least in part because Olsen opposed it, even if DG did plenty of things patterned after DEC.)
1. Is there any similar books about a making of a computer which does not shy away the technical details
2. I'm particularly interested in the Microcode part. I'm taking nand2tetris but I couldn't identify which part I wrote the microcode, or is it non existent in the course?
A classic book about how to design a microprogrammed CPU was "Mick & Brick", which was published by AMD in 1980 and now it is freely available at bitsavers:
This book explains how to design miroprogrammed CPUs with the AMD 2900 series integrated circuits, which was the most popular method for designing PDP-11 clones around 1980, before the monolithic microprocessors from Intel and Motorola became powerful enough to replace the minicomputers.
Even if the bit-slice circuits like the AMD 2900 series have been obsolete for many decades, understanding how a CPU could be designed with them can enable anyone to make now a similar CPU design, but implemented in an FPGA.
The datasheets of the 2900 series, which can be useful for extra details, can be found in the same AMD directory at bitsavers.org.
However, "Mick & Brick" is not for complete beginners. It presupposes familiarity with logical circuit design at the gate level.
"Mick & Brick" - wow! Haven't thought about that one for decades. It was, along with the Apple II schematics, very important in my intro to computers in high school.
The AMD 2900 was, in fact, how the Xerox Star was built. You'll find quite a bit about that choice in Inventing the Future but certainly not gate-level circuit design. As you implied, they made that decision just before decent microprocessors came along in quantity. Even at the time, there were questions about whether it was the right decision.
Mesa was a virtual machine as well as a language, and its opcodes were selected after seeing what Mesa source code was actually written. The goal was to minimize the code size, and then implement the opcodes in microcode.
After the book came out, my friend Jerry and I wrote a lengthy piece [1] about what Xerox should have done, and this time hindsight is allowed.
“some IP may have been repurposed from the Data General Nova” - the default/bring-up Alto microcode* was/is more or less Nova compatible which is hardly IP IMHO. Different hardware by far and never DG software. I think the Nova was the console controller for the PARC MAXC PDP-10 clone hence their familiarity with the architecture.
*Altos and successor D-machines are soft machines.
Oh wow. Seeing the parent post I started musing about Mick and Brick. Surprised I' only the second person who had the same thought. Still have a copy on my shelf.
It's not a technical book, but Show Stopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft[0] compares favorably to The Soul of a New Machine in my opinion. It was originally published in 1994 and reissued in 2008. I haven't see reissue but I know it has an added "Afterward" section that would probably be interesting to read.
I was actually interviewed for the episode but I got left on the cutting room floor because we were able to arrange more interviews with people directly involved whereas I was just second-hand.
/Racing The Beam/ isn't exactly about the creation of the Atari VCS (aka the 2600). It's more about the software side, but scratches a similar itch for computing "pop" history that doesn't shy away from the technical details.
Bryan Cantrill (of Oxide Computer) and co did a podcast a couple of months ago recommending books of a similar vein[1].
I’m not sure if it was mentioned in that episode, but they did another one on the book Losing the Signal about the ride and fall of Blackberry[2] which is worth checking out.
I asked for recommendations in a recent thread, and was pointed at "Skunk Works: A Personal Memoir of My Years of Lockheed", which was pretty good (although not remotely as well-written as "The Soul of a New Machine"), and am reading "Console Wars: Sega, Nintendo, and the Battle That Defined a Generation" currently.
I think there are few books that match both the significance and are as well-written.
You might be interested in this Computer History Museum oral history of Gary Davidian, who among other things (1) worked on the "rival project" from Soul (2) was hired by NEC to bolster their lawsuit defense by writing microcode for the Intel 8086 (3) wrote the 680x0 emulator Apple launched their PowerPC line with.
I also find it gratifying: I worked on 16- and 32-bit Eclipses, and perhaps even a Nova or two in the late 1980s. Once at a customer's site I saw an old blue-and-white MV/8000, on which the sysadmin/programmer said they had run production on one shift while recompiling the older programs on another. (Blue-and-white: the old 16-bit line of DG computers had a blue-and-white color scheme, the 32-bit line had brown cabinets.)
Ahh, I just reread _Soul_! One thing I noticed this time through was the politics and (mostly absent?) leadership from the executives. E.g., the input from the CEO was basically "no mode bit".
I couldn't appreciate those things on the first pass as a young engineer.
To quote "Novell CEO Eric Schmidt" (heh) from the linked Wired article[0],
> [...] and it did a good job of getting into the psychology of leadership. The corporate maneuvering was both fascinating and abhorrent to me.
The joy of rereading a good book, it hasn't changed but I have.
I read TSOANM and Stephen Levy's "Hackers" at about the same time, and they are both foundational to my interest in computer history, which seems to have done nothing but grow recently. Good call-out for a great book!
If you enjoy Tracy Kidder's writing (and I very much do) I would also suggest just about anything by Michael Lewis - his "Liars Poker", "Moneyball", and "The Big Short", to name a few, are really exceptionally well researched and written.
I read both 'The Soul of a New Machine' and 'House' back in college in the '80s. Both had a lasting influence on me personally, and I still reflect on them nearly 40 years later.
I read this recently and loved it, certainly one of the better books I've read in the last decade. I will re-read it at some point, which isn't true of most books I read these days.
But....
Having worked in semiconductors and software, I can't help but wonder if life imitated art or art imitated life.
The grind and machismo around it rang so true to me, but I also disliked how it glorified something that I felt was pretty dysfunctional. I love creating things, but not everything has to be a death march, and surviving it isn't necessarily some badge of honor.
While I see the glory in the engineers rising to the occasion, I also see that the management of that company was clearly to blame for the awful situation in the first place. With that type of management, it's no wonder Data General isn't around any more.
Anyway, I would highly recommend reading 'The Soul of a New Machine'. Just don't take it as an instruction manual on how to run a tech business.