Book Review: Dreaming in Code

I just spent the last four hours lying on the couch reading Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software.  I’ve been dragging this book around for a couple of weeks and finally tackled it.

It was simultaneously depressing, anxiety producing, and inspiring.  I’ve been involved in thousands of software projects over the past 20 years – my first company wrote hundreds of custom applications – ranging from short projects that took weeks to long projects that stretched out over years.  I’ve been involved in numerous different approaches to building software, have worked with amazing teams that struggled to produce anything and average teams that shipped on time and on budget (and all permutations therein.)  While my experiences have been all over the map and my level of deep engagement in the design and development process has lessened dramatically over the years, I never forget the joy of shipping a release.

One of my favorite pieces of software of all time was Lotus Agenda.  I used it for many years after I started using Windows – I think Agenda was the final DOS-based application that I stopped using.  So, when Mitch Kapor (the vision behind Lotus Agenda) announced the creation of the Open Source Application Foundation and the vision of their product Chandler some time in 2002 I was intrigued.

Dreaming in Code chronicles the agonizingly slow creation of Chandler.  The book ends in late 2005, well before Chandler is released.  It’s 2007 and Chandler is still on version 0.7 with the preview release targeted for April 2007.  The vision for Chandler 1.0 is “an open source Personal Information Management (PIM) client application with innovative design and ambitious plans for sharing, extensibility and cross-platform support.” 

I stopped paying attention to Chandler several years ago – I’d lost interest around version 0.4 since it basically didn’t do anything usable.  I just downloaded and installed version 0.7 and the pain from the book washed over me again.  Chandler has a long way to go before it’s useful, and then it’s not clear to me that it’s relevant any more.

Notwithstanding the incredible challenges this project has had, Kapor’s brilliance, patience, vision, and leadership shines through and inspires.  My favorite paragraph was when the author – Scott Rosenberg – asks the question “With all the dispiriting delays, had he ever considered shutting Chandler down?”  Kapor replies:

No.  There were times when I felt horrible depressed.  But I’ve learned in my life, not just there, that if I have very powerful feelings of hopelessness, I should sit with them.  I should refrain from taking action – because those feelings tend to be transient; they tend to be triggered by circumstances.  Instead, just personally, take some time out, whether it’s an hour or a few hours or a day or two.  And that’s as long as it’s ever been with this process to regain perspective.  And every time I’ve come back, saying I believe we can find a way to accomplish the long-term vision by adapting how we about about doing it.”

One of my favorite quotes of all time is from Dune – “fear is the mindkiller.”  Kapor shows us how he copes with it. 

In addition to telling a poignant story of a software project, Rosenberg does an outstanding job of providing a survey course in the evolution of software development.  If you are involved in a company that builds software for a living and want additional perspective on it, Dreaming in Code is worth your time.

  • sigma

    I’ve written a lot of code, and enjoy it, and have contributed at the design level to large, world-class software projects, and I never saw programming anything like the mess the book reports.

    Sounds like the book describes struggles writing good software where, other than just the code itself, too often just gut feel is used for what the software might be, might do, if it does it, if it’s good, and where it might be better. Gut feel is unreliable, essentially irrational stuff. Tough to write down clearly, evaluate, support, test, improve.

    Since the code itself doesn’t mean anything, need some means of solid thinking and exposition about the software other than the code. That thinking and exposition will have to be in clearly written documents in, say, English.

    In particular, before writing the code, need a solid description of what the code will do, a description solid enough to permit rational, reliable development and evaluation.

    Maybe the code writing that book describes is like cooking without a recipe, movie making without a script, building construction without blueprints, etc. If so, then no wonder the work was a mess.

    A pervasive problem in practical computing, and also too serious in computer science, is lack of good skills in exposition and explanation. So, too often the culture has held that the focus is on the code, just the code, with very little before it. For after the code is written, commonly its usage is supposed to be just ‘intuitive’ where, again, exposition and explanation are meager.

    There are good lessons, then, in applied mathematics, physical science, and engineering where code is used for the final calculations but where all the important work is clear and solid in documents nicely done before the first character of code is typed. Given these documents, the programming itself is usually comparatively routine and rarely a mess.

  • Thanks for the review…I will try and pick up a copy of this book.

  • Ross


    As I read this book I had similar feelings, there were many emotional responses triggered by Scott’s writing and the mis-steps of the Chandler team. Like you (as you know) there have been short and long projects tackled and completed over my many years in this industry. However, Mitch’s fortitude is on one-hand remarkable and on the other it is downright “silly” at times – it strikes me that Chandler was DOA before it really got started and should have been put to rest years ago. Who knows what missed opportunities Mitch has had? He should have simply let the source code go to OpenSource and then climbed up a mountain to wait for a revelation of a more relevant vision for the future of software and computing. I know he has the right stuff, but Chandler (I think I can safely say, we have all built before and there was nothing unique about it ever).

    The book was an excellent and fast read.


  • I did a review of Dreaming in code a while back. Really enjoyed the book, in a way it reminded me of what got into writing software.


  • Oh well, this book is pretty awesome! Thx for your detailed review!

  • Thanks for the review
    I gemnacht your side just as homepage

  • Very nice, thanks a lot !

  • Hey pretty good book! Thx

  • Realey interesting story