Does “Dreaming in Code” suck?

Early in my online career — this goes back to around 1990 — I learned a basic principle about off-the-cuff criticism online: No flame flares in a vacuum. In other words, don’t be too glib with your put-downs — because before you know it, the person you’re putting down will find your comment and call you on it.

I recalled this today when I encountered (thanks to a mention on Sumana’s blog) a drive-by attack on Dreaming in Code. In the opening couple of minutes of a talk at Google this past summer, it seems, a Sun engineer named Bryan Cantrill declared, with some vociferousness, that my book — I quote — “sucks.” This judgment is now preserved in the perpetuity that is Google Video.

Now, Cantrill is one of the creators of DTrace, a popular, award-winning and innovative tool for managing Solaris, and my hat is instantly removed to anyone who bears responsibility for a successful piece of software. I am also not particularly shocked to hear that a smart programmer didn’t like my book; he’s neither the first nor the last in that group.

What’s just plain puzzling is exactly what Cantrill has to say in his handful of complaints about Dreaming in Code. Because every point he makes in explaining the basis for the book’s suckiness turns out to be a point that I have made at length in the book itself and in my talks this year about the book — including at Google, several months before Cantrill’s appearance there. Of course I’m not suggesting that he borrowed from me — he almost certainly hasn’t heard my presentation! But I am puzzled how he could so completely have missed my argument, and misrepresented my position, when it seems to be so close to his own.

As best I can make out, Cantrill believes that Dreaming in Code fails to acknowledge that software is uniquely different from other creative endeavors because (a) it’s not a physical entity; (b) we can’t see it; (c) it’s really an abstraction. These factors cause all the analogies that we draw to things like building bridges to break down. Cantrill describes himself as a “finisher” of books and I’ll take his word, but I’m flummoxed how anyone who has finished the book can knock it for failing to understand or express this view of software.

The critique gets sketchy from here on in; Cantrill draws some sort of analogy between Dreaming in Code and Apocalypse Now (a comparison I’ll gladly accept — it’s a reference I make in the book myself) and suggests that I got “hoodwinked” by “every long-known crank in software” (the lone “crank” cited is Alan Kay).

It’s true that the final section of the book surveys both the nuts-and-bolts methodologies that try to alleviate software’s practical difficulties and a whole gallery of software philosophers from both the mainstream and the fringes — people like Kay, Charles Simonyi, Donald Knuth and Jaron Lanier. If even discussing these people’s ideas constitutes “hoodwinking” I guess I’m guilty.

From here Cantrill wanders into his own case for software’s uniqueness, which as far as I can tell is nearly identical to the one I make in Dreaming in Code. “All the thinking around software engineering has come from the gentlemanly pursuit of civil engineering,” Cantrill says. “That’s not the way software is built.” Indeed.

So I’m not sure what the complaint is. Maybe analogies are so odious to Cantrill that he feels they should not even be discussed, even if the discussion is intended to expose their limitations. Maybe the notion of software’s uniqueness and its intractability to old-fashioned physical-world engineering principles seems so obvious to Cantrill that he is appalled anyone would even bother to explore it in a book. But there’s still an enormous amount of attention and money being applied to the effort to transform software development into a form of reliable engineering. I found thoughtful arguments on several different sides of the matter and thought it was worth the ink, although my own conclusion — that software is likely to remain “hard” and not become an easily predictable undertaking — is pretty clear.

Anyway: Go ahead and tell me my book sucks — I can take it! But don’t tell me that it sucks because it fails to acknowledge an argument that actually forms its very heart. Say that and, well, I’m just not going to be able to resist a retort.
[tags]dreaming in code, bryan cantrill, software engineering[/tags]

Post Revisions:

There are no revisions for this post.

Get Scott’s weekly Wordyard email


  1. Well, in my defense, I did explain that the fact that the book sucks isn’t really your fault. And yes, I do think you got seriously suckered by the likes of Alan Kay — but you’re right that I was a bit unfair in that I didn’t really flesh out my criticisms of the book in the talk; I owe you that much at least. (And do note that I brought the book up because I had finished it shortly before I gave the talk — and not because I use it as some sort of strawman sidekick.) I’m heads-down at the moment (writing software, of course), but I will (soon) emerge to give Dreaming in Code its due on my blog; please accept my apologies for the delay between bark and bite.

  2. Joel Norvell


    You must be doing something terribly wrong since large numbers of people actually enjoy this work. Keep it up!


  3. I enjoyed the 2nd part of Brian’s video and frankly I think Brian sincerely cares about our industry and the book did in fact affect him. As an industry we do suck. We are not a mature and predictable industry and we may never become one. Most developers who have shipped successful applications have a hidden fear that they will spend years on a project that will not ship or will not be widely used. Scott, as you pointed out, your views are in fact in agreement with Brian’s and I hope to see his detailed explanation soon.

  4. Scott, I’m 2/3rds of the way thru Dreaming in Code and am enjoying it quite a bit.

    I’ll be buying it as a gift for a few folks I know.

    I feel this way, however, because I can take myself out of my own shoes.

    I tend to think of any piece of media, whether it being books, articles, tv shows, music, whatever, as to be, either intentionally or not, directed towards a certain audience.

    No offense to Bryan or yourself, but I don’t think the book was directed towards folks like Bryan or me. That’s not a slag or a criticism. In my world, if I ever participated in such a project, the principals would have been fired. In Bryan’s – where you are far closer to hardware and OS than the typical corporate developer’s – the reality of things is quite different as well, as he attests in his review.

    I think you more than make up for that by providing differing and interesting perspectives.

    It provides insight on subject matter that is hard to do so – which just happens to be my profession – for folks who don’t have it – and for that – I am very, very thankful.


Post a comment