16 ms·

Reflecting on the Soul of a New Machine

185 points by janvdberg 8y ago

whyisthewhat 8y ago
I loved this book as a kid, although once I got into the work force and began to appreciate the value of a work-life balance and the basically unbrigdeable gap in incentives between management and labor, I started to look at the ludicrous demands the company placed on its engineers with a more jaundiced eye. My perception of the team leader hero, Tom West, was also permanently altered by an essay written by his daughter Jessamyn (a quasi famous technologist in her own right), who described him as basically a depressed alcoholic.
- voltagex_ 8y ago
  I'm having trouble finding the essay - can you give me some pointers?
  - sdenton4 8y ago
    The essay I remember is this one, which isn't nearly so harsh as what the patent comment suggests (but is a lovely read, with good advice): https://medium.com/message/deathhacks-b767903b7c15 https://medium.com/message/deathhacks-b767903b7c15
    - jacquesm 8y ago
      That is worth posting separately.
deanmoriarty 8y ago
I struggled with this a few times: “When a person signed up to do a job for him, he would in turn trust that person to accomplish it; he wouldn’t break it down into little pieces and make the task small, easy and dull.” I’m not particularly talented, far from it actually, but many times I’ve worked in teams with non-junior people who were tasked to do some portion of a project, and simply delivered garbage: a terribly over engineered solution in a component where over engineering was actually very dangerous (e.g. doing distributed systems using several small bespoke moving parts rather than a single solid leader election mechanism, or even better getting away with something leaderless and more elegantly stateless, to give a recent example). In those occurrences, I inevitably “broke it down to pieces” by keeping pointing out all the exact scenarios where the code delivered would fail, until the other person really had to finally move to a solution much more similar to the one I had in mind (much much simpler). Sometimes this required an embarrassing feedback loop of 10+ round trips, where every time I’d just look at the newly delivered code say “this doesn’t work in a X scenario”. And I was not in a better position from a knowledge perspective, we were essentially peers. I felt like a prick and definitely felt resentment from the other party (especially since code reviews are public), but at the same time, how could I have acted differently? The end result was really orders of magnitude better, more robust and smaller.
- tonyarkles 8y ago
  I wish I knew the answer to this, but I don’t. The closest I’ve come to succeeding at this is to have a reputation as a “breaker”. This really started in undergrad algorithms; I wasn’t great at finding solutions, but I had a knack for finding edge cases to break solutions others had come up with. Sometimes it just needed a tweak to work, sometimes it was “throw it all away and start over”. For the few times I’ve done regular office-style work over the years, that’s come in handy. I feel like a dick a too, but I try to be really gentle and end up with people showing up on their own to “run something by me” before building it out. Saves everyone frustration! There have been colleagues though who do exactly what you’ve described. That brutally painful loop of breaking pieces of an overly complicated solution over and over. My unfortunate confession is that I usually end up giving up and let them fail on their own. I’m always willing to help, but if someone doesn’t want help, I won’t spend much energy forcing it on them.
  - korijn 8y ago
    IMHO, Essentially you need to let them experience the issue you foresee first hand, by letting them fail. That way they can learn the same lessons you learned previously.
    - deanmoriarty 8y ago
      In my experience, it doesn’t work that way at all. What happens is that the code will be released, some user will hit the bug in the field, and the issue will be escalated to the engineer, who will proceed to spend entire days or weeks to troubleshoot the problem, and then just put a dirty patch that fixes the specific issue, leaving all the other corner conditions still exposed and ready to explode. At that point, major redesign of the solution, which would have been possible at the code review phase, will just be deemed too risky by both the engineer and the management. On top of this, Management, usually ignorant to concepts such as “over engineered solution”, will praise the heroic effort of the engineer who spent days troubleshooting the issue, clueless of the fact that it was a completely self inflicted wound because the engineer decided that the best way to calculate 2+2 is to really do sqrt(2^4) and then realized that the user really wanted to do 3+3, so they’re going to put a special case to evaluate 3+3 as sqrt(3^3+3^2) rather than just doing the damn x+y. Nobody will even realize that the issue could have been completely prevented in the first place by adopting a solution that was much easier to reason with on the whiteboard, rather than a house of cards of custom logic. I’ve seen this script dozens of time.
packetslave 8y ago
There's a fantastic comment on the article written by Jessamyn West (Tom's daughter): I saw this zipping by on Twitter. Heya I’m Tom West’s daughter and I always pop onto threads about SOANM to bang the drum of good work-life balance as well. My dad was an amazing man and we got along well, but he was a pretty distant dad and basically left the raising of my sister and me to my mom who might have wanted to do something professionally as well. The things he did at work, and his and Kidder’s ability to talk about them, were quite interesting and have lessons that can be relevant in many different timelines and lifestyles. But you know, I wound up moving to Vermont and helping people use technology to solve problems in their lives. You need all the things–technology, an understanding of people, and a life–and my dad possibly only had two of those at any one time. Thanks for writing this.
- greglindahl 8y ago
  Wow, I've worked with her professionally, and had no idea she was connected to a book I read and loved when I was young. Always interesting to hear more of the story around a company and a family.
skybrian 8y ago
For an interesting glimpse of a different trade, I recommend House, also by Tracy Kidder.
spudlyo 8y ago
I've always considered myself lucky that one of first minicomputers I got to know and love was a DG Eclipse. I had the experience of reading the book in college and learning the weird, wonderful, and amazing AOS/VS operating system at the same time. In the late 1980s I got to learn a ton about an operating system that had threads (tasks), virtual memory, shared memory, rich filesystem ACLs, symbolic links, and a bizarre shell language that forced you to do all your looping via recursion. I learned how to program in C on that machine, I wrote some of my first assembly on that machine, and I spent hours pouring over thick black three-ring binders filled with manuals on OS usage, system calls, and the hardware architecture. Friends and I competed to learn arcane details on how the system worked. My main claim to fame was I figured out how to share memory between unrelated processes, and how to use the atomic-test-and-set instruction to safely synchronize access to it. One time while we were studying the virtual memory system, a friend wrote a program to see what would happen if you allocated the entire 4G address space of virtual memory and then randomly touched different pages of it. Predictably, the storm of page faults ground the machine to a standstill, causing our lazy sysadmin to have to put down his his copy of Datamation and address the gathering throng outside his door. I have this recurring dream that I'm back at college for some event, and I wander into the Computer Center and look around. In the very back, there is a dusty 'Dasher' D210 terminal next to some stacked up old furniture -- plugged in and emitting a dim green glow. It's hooked up to our MV/10000 Eclipse, which I imagine is still in the basement of the Library Building humming along after all these years. I try to log in, but I can't remember any of my old accounts and passwords.
- chiph 8y ago
  We had a MV/8000 at college, and it was a really nice machine. We had compilers for Pascal, C, COBOL, and oddly enough, Ada. You could cross-link these languages, so you'd have a front end written in COBOL that would make use of a Pascal back end. And the bindings just worked. You knew when an Ada compilation job had been started because the other terminals would start getting sluggish...
abraae 8y ago
I took a valuable lesson from the book that has served me well over the years. At one point the CEO injects a critical piece of wisdom by telling the engineers they are not allowed to use a mode switch to preserve backwards compatibility. In any system, the presence of mode switches often points to where things will go wrong. If a system has two modes, then inevitably, one of them will be more unloved, untested, under documented and unreliable than the other.
- notacoward 8y ago
  OTOH, in the context of a distributed system that has to be upgraded live and the deployment of new code has to be carefully staged across hours or days (e.g. a storage cluster with thousands of machines), such mode switches can be absolutely essential. The process can look something like this. * Roll out the code with support for a new feature * Flip the mode switch on a few nodes to use the new feature * Wait a while, watch for anomalies * Enable the new feature on more nodes, until it's on all * Disable support for the old feature (another mode switch) * Eventually, roll out new code with the old feature entirely removed It's not quite a whole-system mode switch as in SoaNM, but that's kind of the point. In a distributed system actions do not affect the whole system all at once, so different rules apply.
  - jacquesm 8y ago
    A feature switch is not a mode switch. A feature switch in the 'on' position just gives. A mode switch gives and takes away in the 'on' position.
PhantomGremlin 8y ago
My favorite takeaway from the book was the concept of pinball: if you win, you get to play again. Also the Mushroom Theory of Management. Easy to encounter that firsthand. "keeping them in the dark, feeding them shit, and watch them grow." https://en.wikipedia.org/wiki/The_Soul_of_a_New_Machine#Themes https://en.wikipedia.org/wiki/The_Soul_of_a_New_Machine#Them...
tasty_freeze 8y ago
I read the book when it came out and I loved it. A few years later, in 1986 to be specific, I started a job at an OCR company. My cube was directly across from the office of Carl Alsing, the guy who managed "the microkids". I didn't put two and two together at first. Alsing was one of the people who interviewed me for the job, and I got to know him a little bit for a couple months before someone told me about the book connection. So I went to the library, got the book out, and read it again. When Kidder got to the part where he introduces Alsing, it was amazing. In a paragraph he captured details about Alsing that I hadn't even realized myself (eg, his personality projects the image of a smaller man, though he was actually decently tall). The other thing he got right was Alsing wasn't much for schedules and tended to work on things that interested him instead. Anyway, having verified that Kidder had indeed captured a lot of truth about Alsing, it gave me trust that the rest of the book was similarly accurate, and not just sexed up in the process of storytelling.
microtherion 8y ago
WIRED had a rather nice retrospective on this book in 2000: https://www.wired.com/2000/12/soul/ https://www.wired.com/2000/12/soul/
sureaboutthis 8y ago
It was fun reading the book as I was embedded in all the blue, black and red of wire wrapping my own boards for a mini-computer I designed and built for a company back then. There were times when I wondered if I was doing the right thing and to see that others did the same as I made me feel much better.
EngineerBetter 8y ago
Dang, and there was me hoping for a write-up of the Fear Factory album.
2sk21 8y ago
I read this book when I was in college and it had a profound impact on me - it was one of the primary motivators for me to get into computer science. Then when I came to the US for grad school in the mid 1980s, I got a programming job on campus in a lab and was shown around the computer room by my supervisor. And there I came face to face with the DG MV8000 and gave me a tremendous thrill. For the next couple of years when I worked on that machine (learning C among other things), I used to imagine the scenes from the book.
tosh 8y ago
related: Jessie Frazelle just published this https://blog.jessfraz.com/post/new-golden-age-of-building-with-soul/ https://blog.jessfraz.com/post/new-golden-age-of-building-wi...
mirrorlake 8y ago
There is an interview with a few of the engineers on ScienceFriday's YouTube channel. Definitely worth checking out if you've read the book recently. https://www.youtube.com/watch?v=0wq3ucqnaSk https://www.youtube.com/watch?v=0wq3ucqnaSk
segmondy 8y ago
I just read the book not too long ago myself. Thoroughly enjoyed it. The book that got me going was Hackers by Steven Levy which I've ready easily 20x. This book is just as good. I also think reading this much later in life gave me a fine appreciation as someone in Management of developers, politics, dealing with teams, trusts, motivations, etc. It's actually stunning how relevant the story still applies even tho it was written before most of us were born.
Upvoter33 8y ago
Not everything worth doing is worth doing well -- Tom West
cafard 8y ago
I read bits from the book in The Atlantic (I think) before I ever saw an MV. Some years later, my wife read the book for a class in her MBA program, and I read the whole thing. A couple of points struck me then that may be of interest to the HN readership. First, the instruction set originally proposed by the architect was very VAX-like. It would probably have been great for those writing in assembler. But the end was approaching VAX-like instruction sets. Second, retaining the old Nova/Eclipse instruction set meant that one kept three general-purpose registers (well, sort of general-purpose: by convention, I think the stack pointer was in AC3). One also had no register-relative byte addressing. I liked the Novas and Eclipses, and learned a lot working on them. But the RISC-based UNIX machines took over from the minicomputers pretty quickly. [Edit: I don't think I've used an MV since about 1995--take any remarks with a grain of salt.]

185 points by janvdberg 8y ago

I loved this book as a kid, although once I got into the work force and began to appreciate the value of a work-life balance and the basically unbrigdeable gap in incentives between management and labor, I started to look at the ludicrous demands the company placed on its engineers with a more jaundiced eye. My perception of the team leader hero, Tom West, was also permanently altered by an essay written by his daughter Jessamyn (a quasi famous technologist in her own right), who described him as basically a depressed alcoholic.

voltagex_ 8y ago
I'm having trouble finding the essay - can you give me some pointers?
- sdenton4 8y ago
  The essay I remember is this one, which isn't nearly so harsh as what the patent comment suggests (but is a lovely read, with good advice): https://medium.com/message/deathhacks-b767903b7c15 https://medium.com/message/deathhacks-b767903b7c15
  - jacquesm 8y ago
    That is worth posting separately.

deanmoriarty 8y ago

I struggled with this a few times: “When a person signed up to do a job for him, he would in turn trust that person to accomplish it; he wouldn’t break it down into little pieces and make the task small, easy and dull.” I’m not particularly talented, far from it actually, but many times I’ve worked in teams with non-junior people who were tasked to do some portion of a project, and simply delivered garbage: a terribly over engineered solution in a component where over engineering was actually very dangerous (e.g. doing distributed systems using several small bespoke moving parts rather than a single solid leader election mechanism, or even better getting away with something leaderless and more elegantly stateless, to give a recent example). In those occurrences, I inevitably “broke it down to pieces” by keeping pointing out all the exact scenarios where the code delivered would fail, until the other person really had to finally move to a solution much more similar to the one I had in mind (much much simpler). Sometimes this required an embarrassing feedback loop of 10+ round trips, where every time I’d just look at the newly delivered code say “this doesn’t work in a X scenario”. And I was not in a better position from a knowledge perspective, we were essentially peers. I felt like a prick and definitely felt resentment from the other party (especially since code reviews are public), but at the same time, how could I have acted differently? The end result was really orders of magnitude better, more robust and smaller.

tonyarkles 8y ago
I wish I knew the answer to this, but I don’t. The closest I’ve come to succeeding at this is to have a reputation as a “breaker”. This really started in undergrad algorithms; I wasn’t great at finding solutions, but I had a knack for finding edge cases to break solutions others had come up with. Sometimes it just needed a tweak to work, sometimes it was “throw it all away and start over”. For the few times I’ve done regular office-style work over the years, that’s come in handy. I feel like a dick a too, but I try to be really gentle and end up with people showing up on their own to “run something by me” before building it out. Saves everyone frustration! There have been colleagues though who do exactly what you’ve described. That brutally painful loop of breaking pieces of an overly complicated solution over and over. My unfortunate confession is that I usually end up giving up and let them fail on their own. I’m always willing to help, but if someone doesn’t want help, I won’t spend much energy forcing it on them.
- korijn 8y ago
  IMHO, Essentially you need to let them experience the issue you foresee first hand, by letting them fail. That way they can learn the same lessons you learned previously.
  - deanmoriarty 8y ago
    In my experience, it doesn’t work that way at all. What happens is that the code will be released, some user will hit the bug in the field, and the issue will be escalated to the engineer, who will proceed to spend entire days or weeks to troubleshoot the problem, and then just put a dirty patch that fixes the specific issue, leaving all the other corner conditions still exposed and ready to explode. At that point, major redesign of the solution, which would have been possible at the code review phase, will just be deemed too risky by both the engineer and the management. On top of this, Management, usually ignorant to concepts such as “over engineered solution”, will praise the heroic effort of the engineer who spent days troubleshooting the issue, clueless of the fact that it was a completely self inflicted wound because the engineer decided that the best way to calculate 2+2 is to really do sqrt(2^4) and then realized that the user really wanted to do 3+3, so they’re going to put a special case to evaluate 3+3 as sqrt(3^3+3^2) rather than just doing the damn x+y. Nobody will even realize that the issue could have been completely prevented in the first place by adopting a solution that was much easier to reason with on the whiteboard, rather than a house of cards of custom logic. I’ve seen this script dozens of time.

packetslave 8y ago

There's a fantastic comment on the article written by Jessamyn West (Tom's daughter): I saw this zipping by on Twitter. Heya I’m Tom West’s daughter and I always pop onto threads about SOANM to bang the drum of good work-life balance as well. My dad was an amazing man and we got along well, but he was a pretty distant dad and basically left the raising of my sister and me to my mom who might have wanted to do something professionally as well. The things he did at work, and his and Kidder’s ability to talk about them, were quite interesting and have lessons that can be relevant in many different timelines and lifestyles. But you know, I wound up moving to Vermont and helping people use technology to solve problems in their lives. You need all the things–technology, an understanding of people, and a life–and my dad possibly only had two of those at any one time. Thanks for writing this.

greglindahl 8y ago
Wow, I've worked with her professionally, and had no idea she was connected to a book I read and loved when I was young. Always interesting to hear more of the story around a company and a family.

skybrian 8y ago

For an interesting glimpse of a different trade, I recommend House, also by Tracy Kidder.

spudlyo 8y ago

I've always considered myself lucky that one of first minicomputers I got to know and love was a DG Eclipse. I had the experience of reading the book in college and learning the weird, wonderful, and amazing AOS/VS operating system at the same time. In the late 1980s I got to learn a ton about an operating system that had threads (tasks), virtual memory, shared memory, rich filesystem ACLs, symbolic links, and a bizarre shell language that forced you to do all your looping via recursion. I learned how to program in C on that machine, I wrote some of my first assembly on that machine, and I spent hours pouring over thick black three-ring binders filled with manuals on OS usage, system calls, and the hardware architecture. Friends and I competed to learn arcane details on how the system worked. My main claim to fame was I figured out how to share memory between unrelated processes, and how to use the atomic-test-and-set instruction to safely synchronize access to it. One time while we were studying the virtual memory system, a friend wrote a program to see what would happen if you allocated the entire 4G address space of virtual memory and then randomly touched different pages of it. Predictably, the storm of page faults ground the machine to a standstill, causing our lazy sysadmin to have to put down his his copy of Datamation and address the gathering throng outside his door. I have this recurring dream that I'm back at college for some event, and I wander into the Computer Center and look around. In the very back, there is a dusty 'Dasher' D210 terminal next to some stacked up old furniture -- plugged in and emitting a dim green glow. It's hooked up to our MV/10000 Eclipse, which I imagine is still in the basement of the Library Building humming along after all these years. I try to log in, but I can't remember any of my old accounts and passwords.

chiph 8y ago
We had a MV/8000 at college, and it was a really nice machine. We had compilers for Pascal, C, COBOL, and oddly enough, Ada. You could cross-link these languages, so you'd have a front end written in COBOL that would make use of a Pascal back end. And the bindings just worked. You knew when an Ada compilation job had been started because the other terminals would start getting sluggish...

abraae 8y ago

I took a valuable lesson from the book that has served me well over the years. At one point the CEO injects a critical piece of wisdom by telling the engineers they are not allowed to use a mode switch to preserve backwards compatibility. In any system, the presence of mode switches often points to where things will go wrong. If a system has two modes, then inevitably, one of them will be more unloved, untested, under documented and unreliable than the other.

notacoward 8y ago
OTOH, in the context of a distributed system that has to be upgraded live and the deployment of new code has to be carefully staged across hours or days (e.g. a storage cluster with thousands of machines), such mode switches can be absolutely essential. The process can look something like this. * Roll out the code with support for a new feature * Flip the mode switch on a few nodes to use the new feature * Wait a while, watch for anomalies * Enable the new feature on more nodes, until it's on all * Disable support for the old feature (another mode switch) * Eventually, roll out new code with the old feature entirely removed It's not quite a whole-system mode switch as in SoaNM, but that's kind of the point. In a distributed system actions do not affect the whole system all at once, so different rules apply.
- jacquesm 8y ago
  A feature switch is not a mode switch. A feature switch in the 'on' position just gives. A mode switch gives and takes away in the 'on' position.

PhantomGremlin 8y ago

My favorite takeaway from the book was the concept of pinball: if you win, you get to play again. Also the Mushroom Theory of Management. Easy to encounter that firsthand. "keeping them in the dark, feeding them shit, and watch them grow." https://en.wikipedia.org/wiki/The_Soul_of_a_New_Machine#Themes https://en.wikipedia.org/wiki/The_Soul_of_a_New_Machine#Them...

tasty_freeze 8y ago

I read the book when it came out and I loved it. A few years later, in 1986 to be specific, I started a job at an OCR company. My cube was directly across from the office of Carl Alsing, the guy who managed "the microkids". I didn't put two and two together at first. Alsing was one of the people who interviewed me for the job, and I got to know him a little bit for a couple months before someone told me about the book connection. So I went to the library, got the book out, and read it again. When Kidder got to the part where he introduces Alsing, it was amazing. In a paragraph he captured details about Alsing that I hadn't even realized myself (eg, his personality projects the image of a smaller man, though he was actually decently tall). The other thing he got right was Alsing wasn't much for schedules and tended to work on things that interested him instead. Anyway, having verified that Kidder had indeed captured a lot of truth about Alsing, it gave me trust that the rest of the book was similarly accurate, and not just sexed up in the process of storytelling.

microtherion 8y ago

WIRED had a rather nice retrospective on this book in 2000: https://www.wired.com/2000/12/soul/ https://www.wired.com/2000/12/soul/

sureaboutthis 8y ago

It was fun reading the book as I was embedded in all the blue, black and red of wire wrapping my own boards for a mini-computer I designed and built for a company back then. There were times when I wondered if I was doing the right thing and to see that others did the same as I made me feel much better.

EngineerBetter 8y ago

Dang, and there was me hoping for a write-up of the Fear Factory album.

2sk21 8y ago

I read this book when I was in college and it had a profound impact on me - it was one of the primary motivators for me to get into computer science. Then when I came to the US for grad school in the mid 1980s, I got a programming job on campus in a lab and was shown around the computer room by my supervisor. And there I came face to face with the DG MV8000 and gave me a tremendous thrill. For the next couple of years when I worked on that machine (learning C among other things), I used to imagine the scenes from the book.

tosh 8y ago

related: Jessie Frazelle just published this https://blog.jessfraz.com/post/new-golden-age-of-building-with-soul/ https://blog.jessfraz.com/post/new-golden-age-of-building-wi...

mirrorlake 8y ago

There is an interview with a few of the engineers on ScienceFriday's YouTube channel. Definitely worth checking out if you've read the book recently. https://www.youtube.com/watch?v=0wq3ucqnaSk https://www.youtube.com/watch?v=0wq3ucqnaSk

segmondy 8y ago

I just read the book not too long ago myself. Thoroughly enjoyed it. The book that got me going was Hackers by Steven Levy which I've ready easily 20x. This book is just as good. I also think reading this much later in life gave me a fine appreciation as someone in Management of developers, politics, dealing with teams, trusts, motivations, etc. It's actually stunning how relevant the story still applies even tho it was written before most of us were born.

Upvoter33 8y ago

Not everything worth doing is worth doing well -- Tom West

cafard 8y ago

I read bits from the book in The Atlantic (I think) before I ever saw an MV. Some years later, my wife read the book for a class in her MBA program, and I read the whole thing. A couple of points struck me then that may be of interest to the HN readership. First, the instruction set originally proposed by the architect was very VAX-like. It would probably have been great for those writing in assembler. But the end was approaching VAX-like instruction sets. Second, retaining the old Nova/Eclipse instruction set meant that one kept three general-purpose registers (well, sort of general-purpose: by convention, I think the stack pointer was in AC3). One also had no register-relative byte addressing. I liked the Novas and Eclipses, and learned a lot working on them. But the RISC-based UNIX machines took over from the minicomputers pretty quickly. [Edit: I don't think I've used an MV since about 1995--take any remarks with a grain of salt.]