"Dreaming in Code" by Scott Rosenberg

Many of you have probably read the classic The Soul of a New Machine by Tracy Kidder which chronicles the building of a minicomputer at Data General in the late seventies. Earlier this week the torrent finally let up (no it didn’t stop raining) and spring break descended so I made a trip to the bookstore. There I found a book proclaiming on the back jacket to be the first true successor to The Soul of a New Machine, Dreaming In Code by the cofounder of Salon.com, Scott Rosenberg. Dreaming in Code chronicles the trials and tribulations of the creation of Chandler, an “interpersonal information manager that adapts to your changing needs”, which, if you visit the website linked above, you will discover is still at version 0.7. The book is an interesting, quick, if somewhat depressing read, I must say. Having myself never been involved in software development beyond my own hacking around with little personal programs, I found the picture painted of how code is developed to be interesting. Indeed, I can see in my own methods for programming many of the traits which are described as impeding good software development in a team setting: the desire to do it all yourself, the desire to reinvent instead of reuse, the desire to overdesign, etc etc. If nothing else, this book is probably a great read for anyone on the path towards becoming a software delevoper: not really a warning so much as a case study of the trials of tribulations of dreaming in code.

One Reply to “"Dreaming in Code" by Scott Rosenberg”

  1. “Soul of a New Machine” is a wonderful book, as are several others of Kidder. It had something to do with why I left physics for industry back in the 1980s. Most of my work since then has been designing digital logic. Computer design is just as fun as Kidder describes it.
    I think that the desire to redesign instead of reuse is present in every good designer. The question is how much one can ignore the internal details of a black box.
    So long as the black box has a sufficiently simple interface to the rest of the world (and the designers of the box met that requirement), black boxes are useful to use. However, my experience is that management tends to minimize the problems with adapting black boxes, especially those with complicated interfaces.
    A good black box would be one with an I2S interface. The complications become something for software to deal with. For more complicated black boxes, like a memory interface or a PCI bus, my experience has been that reuse is much more difficult than simply starting from scratch.
    So long as the thing works, one is okay. But when one has to debug them, the problem can become impossible. If you have the original designer, you can deal with it. But more often, one is provided with an encoded netlist that is impossible to debug. These are worse than useless, but the lure of having a quick and easy design make them very attractive to management.

Leave a Reply to Carl Brannen Cancel reply

Your email address will not be published. Required fields are marked *