Dreaming in Code

14 Jun 2007 08:05

This book examines the software development process by following the progress of Chandler, a (still unfinished) Web 2.0/open source personal information manager dreamed up by Lotus founder Mitch Kapor.

In Dreaming in Code, Scott Rosenberg, founder and former editor of Salon.com, refers to Brooks frequently. The book follows the progress of Chandler, a project dreamed up by Lotus founder Mitch Kapor. Chandler is a personal information manager, a category of software that used to have many interesting players, each with its own paradigm, most of them killed after Microsoft released Outlook. One of Kapor's pet projects before he left Lotus was Agenda; Chandler shares the same ethos, although reinvented for Web 2.0. And open-source.

Why is writing good software so hard? One reason, Rosenberg suggests late in the book, is the way people are taught to write code. A poet studies the great works of the past; a programmer tries to think of the steps a computer must follow in the right order. The great classics of a programmer's genre are, typically, kept secret: commercial software isn't published for new programmers to learn from. Anyone can dissect the workings of a Jane Austen novel, but no-one can learn from the code of Windows.

There is a famous scene from the movie Spinal Tap in which the Stonehenge set, built in inches instead of feet, is in danger of being crushed by a dwarf. Rosenberg invokes it to explain the problem of specification. In that case, all that needed to change was a double to a single quote on the back of that napkin. But in programming the perfect spec would never be completed. Even an apparently simple statement of a user requirement 'users should be able to share information easily' runs into major confusion as people disagree on what it means and try to write a spec to which programmers can code.

Programmers are, of course, notoriously hard to manage — but that's as much due to the nature of software as it is personalities. How do you really tell what a programmer is doing, or whether they're producing anything? What they do need to do, though, is communicate, both informally to solve problems and formally to managers. But these days there are almost too many channels. As early as 2002, Chandler had a private mailing list, four public mailing lists, an IRC channel, Bugzilla bug tracking and a wiki. The upshot is reminiscent of those early time-sharing mainframes that spent so much time prioritising tasks that they had no resources left to do any computing.

Watching people struggle to create new technology is by now a time-honoured genre. Tracy Kidder (DEC), Jerry Kaplan (Go) and Steven Levy (the Apple Mac) have all covered this sort of ground. They all had one advantage over Rosenberg: they knew how the finished product came out. Rosenberg, however, had to go to press leaving Chandler mid-coding. It remains unfinished even now. But then, you see, this book has only one author. That helps.

Story URL: http://reviews.zdnet.co.uk/software/productivity/0,1000001108,39287541,00.htm