posted on April 30, 2007 16:23
Dreaming in code helps to describe why creating software is hard, more importantly why software that will change the world is hard to create. The analogy used is "Why building software is not like building bridges." Scott Rosenberg (cofounder of Salon.com) follows the development process of OSAF's
Chandler project, a personal information manager (PIM). Chandler was deemed "The Outlook Killer" in January, 2003 by Wired Magazine. 4 years later, Outlook is still around and Chandler is still in an alpha stage.
I found it amazing how many open source "Software Legends" where drawn to the project. Some volunteers others were paid. Personally I don't see why the project was so interesting. While reading the book, I never thought the software "would change the world" as many others did. With so many software heavy weights, interjecting their opinions I can see how the project was doomed. In my opinion there should be one person in charge of major decisions. Linux has Linus, C# has Anders, Chandler should have decided to put one person in charge and make the architecture decisions final. One person as a "ring leader" helps to steady the project.
Many times while reading the book I became frustrated at the processes that the Chandler project used. One thing about the project that really frustrated me was they started to create the user interface before they decided on the backend. A significant amount of time was lost due to this issue. If they would have decided how the data would be stored, then the user interface would not have taken so long.
I think most people are aware of the Standish Group study in 1995 which"... Of the challenged or canceled projects, the average project was 189 percent over budget, 222 percent behind schedule, and contained only 61 percent of the originally specified features". I think many of OSAF's problems are representative of many software companies
Dreaming in Code is a great book for describing the day to day interactions of a software development company. What kept me reading the book, was great interjections and comparisons, such as a quotes from Joel Spolsky, Eric Scott Raymond, and Fredrick Brooks. The author compared many of the issues of Chandler project to patterns recognized by Fredrick Brooks in the "Mythical Man Month" and "No Silver bullet" which were published over 20 years ago.
After reading Dreaming in Code, the first thing I did was download the bits and started looking though the code to see what the big deal was. Why did they encounter all these issues? My conclusions thus far, there are many lines of code that do not accomplish much. It was also obvious that much of the code was written by java developers.
Dreaming in Code is well written and followed the project very closely. Sometimes reading about a losing company helps put things into perspective. This book is recommended to others programmers and non.