Review: Dreaming In Code

Scott Rosenberg follows the Chandler project as a reporter, unraveling the mysteries of software development gone wrong. What's interesting for me, at a personal level, is that I know several of the principles through work at a previous life: Katie Capps Parlante, and Aparna were both with me at Escalate, ironically, a startup that failed for business reasons. (To give you an idea of the quality of the folks at Escalate, at this point, 4 of its first 20 engineers are at Google, while another 4 or 5 are at Yahoo)

The part of the narrative that sticks out to me like a sore thumb is the lack of impatience at OSAF. In fact, the general approach was so muddled that even software luminaries like Andy Hertzfeld left. When building a project, the most important thing to do right away is to build something that works as quickly as possible and get it out there. It doesn't have to be pretty, and it definitely doesn't have to have a fancy object layer. It has to work and do something useful. That gives you a user base that can drive more feedback to help you refine future versions. On top of that, once you have a significant user base among early adopters, you'll get more contributors to your open source program, and the code will snowball. The architecture astronauts approach, however, seemed to have overtaken OSAF, which led them down the garden path of building infrastructure first without an application in mind. I don't under-estimate the importance of infrastructure: I build it all the time, as does the company I work for, but infrastructure for the sake of infrastructure is wasteful, as you'll invariably build the wrong thing.

The book is well-written, and worth reading, even if you work in software on a daily basis. If you're successful, you'll say to yourself, "at least I'll never get caught in this morass." If you're unsuccessful, you'll comfort yourself by Rosenberg's repeated assertions that software is hard. Ultimately, however, there are lots and lots of ways for software projects to fail, and only a few ways for them to succeed, so this book is another reminder that unfortunately, the state of software engineering is such that you can go years without reading many new books and still be ahead of most of the field.

I met Rosenberg when he visited Google to promote the book. As he signed my copy, I quoted one of the original hackers Brian Harvey, "All the best software is written by one person." Rosenberg repeated something obviously told to him by many other practitioners, "The software systems we build now are too big, too complicated for one person." I told him that I didn't believe that for a minute. Even in his book, you could trace many programs to one person: Alan Kay and Smalltalk, Charles Simonyi and Bravo. I can name more modern examples: Paul Buchheit and Gmail, Louis Monier and AltaVista, Larry Wall and Perl, Linus Torvalds and Linux. Sure, as the programs evolved and grew, more and more people got involved and ended up building a big system. But right at the beginning you can only have a program written by one or two engineers to scratch their itch. While Rosenberg wasn't willing to write-off Chandler yet, I am. Today, Google's calendar does everything Chandler's trying to do --- by designing the program by committee instead of Mitch Kapor rolling up his sleeves and just writing code, OSAF has doomed Chandler to permanent irrelevancy.

"We've consistently overinvested in infrastructure and design, the fruits of which won't be realized in the next development cycle or even two---that is, not in the next six or twelve months. You pay a price for that in a loss of agility. The advice I would give is to do even more of what we've been doing in the last couple of years, which is to sequence the innovation, stage things, and be less ambitious..."