Anyone who has ever worked on a large software project that has gone seriously awry and is behind schedule will do as I did: wince their way through Scott Rosenberg’s Dreaming in Code. Dreaming in Code is an account of the three years (and counting) spent designing and developing Chandler, a Personal Information Management (PIM) system, led by Mitch Kapor, the creator of Lotus 1-2-3 and the author of the seminal Software Design Manifesto, which should be required reading for all interaction designers. [Full disclosure: Mitch is a client and my experience working with him and his team was nothing like the quagmire detailed in DIC. It was challenging but fun, and Mitch is a visionary guy, able to leap between big picture and tiny details. Always have clients who are smarter than you.]
Chandler itself is a visionary idea, one that is similar to MayaViz’s CoMotion software in that it treats all bits of data (addresses, calendar entries, email, etc.) as fluid objects that can change and be used in different forms. Building that idea turns out to be a massive problem, as is detailed (sometimes in almost too much detail) in DIC. Readers who don’t have any programming background will likely find themselves occasionally glossing over some of the technical discussions and details, but as an introduction to what it takes to create a piece of software and as a primer on software history and methodologies, DIC is really top-notch. Very readable and it untangles subjects like programming methodologies more clearly than anything else I’ve ever read on the matter.
If you’ve never done a project like Chandler, this book is a window into what it can be like, although, as the book points out, every project is different. The Chandler team inadvertently makes a series of painfully bad errors in process, starting with the two years they spend without a solid design to work from, then their choice of a programming language none of the developers was an expert in, and even (as it turns out) in the choice of medium (desktop vs. online application). Then, as the slog continues, through its alpha releases, you are left just shaking your head: first in exasperation, then sadness, then resignation. It’s a wonder that any big software project gets done.
There’s some great pieces of wisdom tucked into this book as well. One in particular, to explain the slow start of the project, notes that it is always easier to make tools (and tools for the tools) than it is to make the product itself. Something that designers with our love of models also need to beware of.
Recommended.