January 3 2007
Yesterday, Joel Spolsky mentioned that he's looking forward to reading a new book, Dreaming in Code. I'm way behind in my industry-related book reading, having been distracted by life, primarily, and a goal to read all the Harry Potter books in order (ok, so I wasn't an early adopter on that). But I'm going to add this book to the list, because it breathlessly promises real drama:
It poses a question and tells a tale. Why is good software so hard to make? Since no one seems to have a definitive answer even now, at the start of the twenty-first century, fifty years deep into the computer era, I offer, by way of exploration, the tale of the making of one piece of software -- a story about a group of people setting their shoulders once more to the boulder of code and heaving it up the hill, stymied by obstacles old and new, struggling to make something useful and rich and lasting.No doubt, creating software is hard. My first project after college graduation was of the "build Rome in a day" variety, with a programmer who thought the height of database design was colon-delimited ASCII. Even with the low-fidelity design goals, that project took years (and was shelved rather than go into production). Starting from the ground up takes work.
Dreaming in Code documents the building of Chandler, which was billed as the end-all be-all information manager, starting with e-mail and calendaring as a foundation. Spolsky says:
I've been watching Chandler closely ever since it was probably doomed by being breathlessly hailed by Wired Magazine as "The Outlook Killer" in January, 2003. Well, it's January 2007 now, Outlook isn't dead, and Chandler is up to 0.7alpha4. Being hyped by Wired Magazine is almost certainly a bad sign. I've been wondering what the heck went so wrong on the Chandler team, or perhaps it's just a matter of good software taking ten years? Usually the first useful version takes less than that, though.The "ten years" link takes you an article where Spolsky happens to highlight the success of Lotus Notes, and how long it took, with development first starting in 1984, first ship in 1989, and exponential growth not starting until around 1995. Then the fun really starts, and you get into the "Innovator's Dilemma" trap. Some of the nimbleness of the Web 2.0 technologies, like the first Internet boom, is they have no installed base to worry about. Once you get big, then you have to approach development from a very different angle. Anyone notice, just as one example, how long Blogger's new release was in beta? And what's the upgrade rate been to that new release?
It will be interesting to see whether this book takes an honest look at the pace of the Chandler project. While they've been in development, IBM Lotus has shipped Notes 6 (a month before they started), Notes 6.5, Notes 7, and beta of Notes 8 (and it looks like Notes 8 will ship well before Chandler gets to 1.0). New players like Zimbra have emerged from nowhere and built similar functionality in a web-only footprint. Mitch Kapor, described as "Chandler is his baby" in the book excerpt, seems to be more-focused on other efforts. And watching the project, touted heavily as an open-source effort, makes it clear that a whole lot of the work is really being done by OSAF themselves, and not outside contributors.
This is, perhaps, why every time someone hypes the next big thing as the next Notes killer, I tend to be less concerned (though not unconcerned) than I used to be. The pace of innovation for Notes itself continues to impress when you consider the number of platforms, languages, and the commitment to backward compatibility. With Notes 8 representing the biggest leap forward yet in terms of what Notes does, I can only think that the hundreds of engineers working on the project are "dreaming in code" -- and dreaming of that exciting day, later this year, when this exciting and pivotal new release comes to market.