Belated comments on Dreaming in Code
Back in February I mentioned Scott Rosenberg’s book Dreaming in Code. Somehow I never got around to posting more extended comments. Recently I was asked, by someone who had followed the Chandler project but hadn’t seen the book, to clarify why I thought the story was sad. This post is a cobbling-together of my answer to that question as well as some comments I made in the course of our group-interview on the Well. (Short of reading the book, you can learn quite a bit about it from the many interviews Scott has given.)
I said I found it a bit sad because of the divergence between the early goals of the project and the reality of it several years later. Massive schedule slip was the main thing, but there was also a serious scaling back of some initially ambitious and interesting UI goals. As a final kicker, nobody would attempt to build Chandler as a desktop app today – even a casual Web 2.0 user would look at it and say, that should be on the web!
One thing I appreciated was that Scott didn’t pre-empt earlier parts of his story based on later developments. Naturally, as I sat here in 2007 reading about OSAF’s 2002/2003 plans to make a networked PIM, I thought, “They’re not doing this on the web! They’re doomed! Why isn’t he talking about that?” He does talk about it, of course, but later, after walking us through those pre-Ajax-explosion days.
From my reading of events, the team sure could have used an injection of short-iteration development religion. It was painful in parts to read about them spinning their wheels over design decisions with no runnable code being produced. It seemed pretty clear to me that hard ship-dates were not actually a very high priority. Certainly Kapor could have made a hard requirement at the outset that a usable rev be shipped every, say, three months. But he didn’t. That’s a legitimate choice IMO. But maybe a fatal one for this particular project.
The book inspired me to revisit other books on software – by the time I finished it I had pulled out The Mythical Man-Month, The Pragmatic Programmer, and Knuth’s Literate Programming.
Finally, this book feels very much a part of the legacy of the Whole Earth Catalog philosophy: the world is a complex but ultimately comprehensible place, and interested non-specialists have as much place learning how a particular corner of it works – and how the work in that corner might improve the world – as anyone else.
It’s clear that Rosenberg has a deep interest in software. That was really driven home by his story about collecting tiny snippets of different programming languages; he’s not just an anthropologist of an alien culture. And yet he remains a writer of sentences and paragraphs, not functions and procedures. I’m looking forward to seeing where this interest takes him next.