I recently finished the book Dreaming in Code (which I got for sort-of free, excluding income tax, courtesy of affiliate links just like that -- I'd forgotten that I even had any of those on here, but apparently some ancient article on SQL Server Hierarchies has a couple), grabbing a copy after it started appearing in all of the "customers who bought this book also bought"* sections for other books I was contemplating.
Wonderful book.
It documents the progress (or lack thereof) and missteps that occurred during the lengthy birthing of Chandler, an open source Outlook/Exchange "Killer".
Started with a lengthy, largely abstract wish list, and an ability to use whatever technologies and techniques that they wanted -- financed by the deep pockets of the undemanding Mitch Kapor -- Chandler was the sort of project that developers dreamily contemplate while analyzing the patterns on their cube wall, imagining how much better it would be than the tight confines and demanding deliverables of their current reality.
Chandler was the sort of project where the only apparent limitation seemed to be the collective imaginations of the contributors. The sky was the limit!
The result of such free reign and lack of demands can only be classified as a disaster: After a long period of development by a fairly large and expensive team, the releases thus far have been a rather dubious calendar product, in a very alpha state, and a server product that backtracks on many of the initial goals (for instance the "P2P solves everything" silver bullet).
It's difficult to categorize this book: It really isn't a how-to book at all. Nor is it really a book for a layman, as it frequently goes into a level of detail that could be daunting (sometimes the level of technical detail seems a bit like filler, not really playing a part in the telling of the story. Unnecessary detail for the story, but too little detail to be of interest for a technical analysis).
Really it's a how-not-to book: A reporting of many of the classic mistakes of software development happening in a real, visible project, and how they impacted the progress. The OSAF (Open Source Applications Foundation) team certainly isn't the first to make these mistakes, and they certainly won't be the last, but they had an uncommon honesty and openness to allow a reporter to document their every step.
I would imagine Mitch figured this would all turn out quite a bit differently, with Chandler rocketing to Firefox-like success, and this book documenting the new age approach to software creation.
This book came to mind yesterday when I hit publish on the "Most Destructive Metric In Software Development" entry. In that entry I mentioned that developers abhor using other people's code when they have the option of spinning something "original" themselves, and this materializes several times during the Chandler project. After eliminating the Zope ZODB (a Python object database) from consideration, for instance, and going off and going through several iterations of their own database, the individual behind the decision declared that they "never really looked at ZODB".
Classic.
* - Around four years ago we bought the great book "The Baby Name Wizard", and found it to be a helpful in choosing names for our first child. We're now a month away from welcoming our third child, and have begun the name contemplation game, and I just received a "People who bought the Baby Name Wizard also like..." email from Amazon. Their system has more inputs than I imagined.