Review By: Dmitri Ilkaev
06/14/2008Dreaming in Code is the story behind Mitch Kapor's OSAF, an ambitious plan for developing a much better contact management tool (known as "Chandler") than anything else that is currently in use. A significant part of the book chronicles the Chandler project, discussing dead ends and sudden breakthroughs, missed deadlines, personality clashes, and all other typical software development "internals." These were described by the author in terms of black holes, turtles, snakes, dragons, axe-sharpening, and yak-shaving. Add to this narrative stories about staff bringing more and more pets to the office, and a very colorful style of Rosenberg’s writing, and you'll get quite an exciting reading for a couple of days.

It is difficult to determine who is the audience for this book. Rosenberg writes a good deal about basics like variables, binary code, Hungarian notations, garbage collections, etc. These excursions may bore technical readers, while more advanced topics will definitely not be out of reach for individuals without software development experience.

Rosenberg takes a break in the middle of the book to review the history of the computer industry's efforts to make programming a more efficient process. He provides a short description of theories and methods of software development, covering the transition from FORTRAN spaghetti code, to structured and OO programming. He documents the evolution of software development covering topics such as waterfall, RAD, spiral, and capability maturity model (CMM). Rosenberg finishes with a discussion of agile methodologies and Extreme Programming.

He shows that the problems we are experiencing today were accurately predicted by programmers thirty years ago, such as observations described by Fredrick Brooks in "The Mythical Man-Month.” While Rosenberg finds that every software programmer finds his or her own unique path to a brick wall in the development process, he also tries to show why. Even with the modern computing power and advances in programming techniques, the creation of a new application remains challenging.

If you're in the business of software development, you'll find almost everything in the project story to be painfully familiar: schedules delays and shifts, scope creep and unclear requirements definition, general vision instead of detailed and formal descriptions and typical characters being involved in these situations. The experienced technical reader will catch deficiencies in design, such as synchronization without server, aggressive plans on cross platform portability, etc. Rosenberg will likely confirm your feelings by noting that, "By now I know any software developer reading this volume has likely thrown it across the room in despair, thinking, 'Stop the madness! They're making every mistake in the book!'"

Rosenberg had written his book before the Chandler project had been completed; however, he felt he had experienced enough to give a true picture of how software is made. The abrupt closure of the book may be frustrating for some readers who are looking for resolutions, conclusions, and recommendations. It should be noted that while the book is about an open source project and shows what would be considered an average project team, the project itself is not average in that they are working without money and time constraints, which most projects face. When talking about the many challenges of software development, Rosenberg did not fully cover the other end of the software development spectrum: that there are hundreds and thousands of big and small commercial innovative software projects being delivered on time and on budget.

The author demonstrates his superb ability to describe a complex, sophisticated, technical subject in a clear and understandable manner; and he shows how people innovate and communicate during this process. Through the book he creates a great level of excitement about the project itself, as well as software development process; presenting it both as a science and an art.