Thursday, May 15, 2008

Book Review: Dreaming in Code

Chandler was supposed to be Mitch Kapor's modern incarnation of his Lotus Agenda product. I've never used Agenda, but I've seen it demoed and I know some people who loved it. One of its problems was that it defied description, but the best I heard was that it did for text what spreadsheets did for numbers. it wasn't word processing but organizing lots of text records whether they were contact information, calendar events, notes or whatever. Agenda was the first Personal Information Management (PIM) software.

One of things I thought of doing when I started this sabbatical was contributing to Chandler. FIrst I needed to learn the Python programming language. I had started that but I was more interested in the Mac and spent time learning Objective-C and some Cocoa and participating in the Quicksilver community. And the Open Source Applications Foundation (OSAF) was making very slow progress on Chandler.

dreamingincode.jpgScott Rosenberg wanted to write about the software development process and why it was so difficult. Early on he decided to use the Chandler project as his case study and they gave him tremendous access. The problem was the project had a very difficult time making progress and defining what it wanted to be. The result is the book Dreaming in Code and the subtitle says it all: "Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software"

There are comparisons between this book and Tracy Kidder's The Soul of a New Machine (in fact they are right on the back cover). I don't expect this to win a Pulitzer as that did, but I found it to be a quick fun read.

Rosenberg is a journalist, not a programmer but as co-founder of salon.com he's been involved with a company dependent on software. He's writing for the non-programmer as well and I'm not sure I'm qualified to know if he made things intelligible. Descriptions of meetings and issues rang true to me. To give things context he explains some software history, including projects, personalities and even some famous bugs (some I hadn't known about).

Things like how Guido van Rossum invented the programming language Python and named it after Monty Python because programmers love Monty Python just add a little color. The stories of Stallman starting GNU and Linus building the kernel and Raymond describing open source as the Cathedral and Bazaar are standard fare and probably will sink in. The Mythical Man-month and Agile methodologies and even descriptions of Hungarian notation probably also work. I doubt any non-programmer will follow his explanation of the halting problem. As you may notice, there are a lot of these asides from the main story and when he refers to luminaries like Knuth or McCarthy at the end, I'm not sure people will remember which ones they were.

As for Chandler itself there are descriptions of various meetings and issues that went back and forth (and back and forth). I read about some technical issue and then was shocked to see that these debates went on not for a couple of days but for weeks and that months went by without some fundamental things being decided. With a little bit of thought I remember being in a few of these kinds quagmires, but I don't think ever this bad.

It's not at all clear why the project had so many problems. The book describes the differences between doing detailed specs up front and using a more agile small incremental improvement approach. But that really didn't explain the issues here. I can't believe they didn't do the standard thing and punt peer-to-peer to rev 2.0. With some of the people they had there it could have been too many chefs, but it didn't sound like it. My best guess is it was leadership that wasn't willing to say no or make a six-of-one half-dozen-of-another decision. It could have been merely that they were doing really hard things, but it didn't sound like that was the issue and that doesn't explain why so little progress was made. The book doesn't mention that in January of this year Kapor left the OSAF. It will be interesting to see if things speed up at all.

No comments: