In short: I enjoyed the book and recommend it – it’s a good, though uneven, book exploring why software is hard to make. I read most of it in one night and finished it off in a second, and despite anything else i say, that’s an endorsement of any book of any kind.
However my take on the book is unavoidably hurt by its lead praise from James Fallows, of The Atlantic, who said ‘The first true successor to Tracy Kidder’s The Soul of a New Machine’, in reference the Pulitzer prize and National book award winner that defined the ‘computer engineering as human narrative’ genre. Kidder’s book was personally seminal and I have respect for Fallows, but it’s misguided praise, and worked to Rosenberg’s disadvantage. I don’t think his intent as an author was to write the same kind of book, and the comparisons in my mind didn’t help. However, as an author I’m ambivalent on the appropriateness, or dangers, of comparing a book based on what it’s blurbs say, so I’ll leave it at that.
Dreaming in code is three books woven into one: one of them is a narrative story of of the Mitch Kapor led project to create a new PIM application called Chandler. The other threads introduce software concepts (e.g. explaining object oriented programming and how Python differs from C++) and explores why software is hard to make. All big topics, and fun ground for Rosenberg’s curiosity and intelligence to explore. The book struggles however with keeping them together: the 3 threads are uneven, and I was often unsure where he was going, or when we’d get back to the Chandler story, the one I expected to be, based on the cover and Kidder reference, the focus of the book.
For example, the book dances between assuming the reader has tech-interests vs. being a layperson, with side threads into esoterics like Hungarian notation and Literate programming, that made me wonder. Most books in this genre don’t go that far, drawing the line around the depth of what a magazine feature article would explain: even Digital woes, a favorite book on why software fails, nails the topic without getting into construction or showing code samples.
Steven Levy’s Insanely Great, about making the Macintosh computer, or Zachary’s ShowStopper, about Windows NT, are classics in this genre, and unlike them Dreaming in code has a higher degree of difficulty: it doesn’t have a star central project at the book’s core. I would never have heard of Chandler without picking up the book. Mitch Kapor and Andy Hertzfeld, industry pioneers and legends, play leading roles which adds some star power, but they’re not the focus.
And without the natural tension of a big well known project, the players in the book feel light: the drama and passion that are integral parts of good projects aren’t there (and it’s something Kidder went to great lengths to capture). I can’t tell if that’s Rosenberg’s polite reporting, or something missing in the project itself, but the emotional commitments of people to each other, and the project, is critical to making good software, and might be the secret Rosenberg seems to seek in the book, but it’s never mentioned.
That said, Rosenberg is smart and insightful, and the book has its share of gems. Ideas from many luminaries are touched on, from Doug Englebart, Fred Brooks, Alan Kay, Richard Stallman, Don Knuth, Watts Humphrey and more. The result is a good, often charming book, that would be good fodder for a team to read together, discussing their own opinions as each chapter unfolds.
But with the rickety management example of Chandler at the book’s core, software management, as a discipline, is portrayed as an immature, misguided, geeky business: perhaps an accurate snapshot of the average team today, but not of the best. Rosenfeld doesn’t give serious context until the last 1/3rd of the book, when Joel Spolsky, 37 Signals, and Google’s theories surface as cautious remedies to the challenges Chandler faced, but the vibe is cynical, and I found myself, especially with Chandler as the example, defensively optimistic about what a good project manager could have done.
As a sweet side note, Rosenberg did uncover thought provokers I hadn’t heard before:
- Alan Kay’s wonderful software as a doghouse metaphor
- Linus Torvalds on how you should start large projects
- Richard Gabriel’s passionate criticism of programming education
Rosenberg’s perspective cuts both ways: his outsider view is an advantage as he asks questions veterans and gurus have forgotten or are scared of, which paves new ground on old topics. But it you want guidance, harder critiques, or expert analysis of what to learn from Chandler, you’ll need to discuss the book with someone else, or look elsewhere.