What makes software so hard? Why does it take so long to develop? Why is it always late, always full of bugs, always over budget? In "Dreaming in Code" by Scott Rosenberg, he explores these questions from a historical perspective, and through anecdotes from the Open Source Applications Foundation (OSAF) project "Chandler". The story of the Chandler project, founded and funded by Mitch Kapor in 2002, serves as an anchor to which Rosenberg attaches the history of software development and management. It turned out to be an interesting choice, since the Chandler project came without a deadline, with "unlimited" funding from Kapor's pocket, and with very enthusiastic collaborators. Nevertheless, they hit the same hurdles as pretty much any large complex software project have, including being stuck in "software time", communication overhead, planning and time estimate problems, delayed releases, and thousands of bugs.

Between the project anecdotes, Rosenberg surveys the software development and management literature, and gives a brief glimpse into its history. He frequently comes back to Fred Brooks' "The Mythical Man-Month" and concludes that the communication overhead grows exponentially, even with today's online always-connected tools. And there is still no silver bullet to solve it. He touches on various methodologies and processes, including the Capability Maturity Model (CMM); Team Software Process (TSP); Rapid Application Development (RAD); Agile Software Development; Extreme Programming. All of which were supposed to assist a software project and guarantee some kind of success, but which in the end come with their own short-comings and pitfalls.

Given that Chandler is already history, it is not a spoiler for the book to mention that the project failed. It was designed and planned as a native application, right before AJAX and Web 2.0 become buzzwords, and much of the functionality it tried to deliver have now been covered by large web services like Google's Apps suite, Microsoft's Office365 and similar. Still, there is plenty to learn from its story.

Learn from it

Rosenberg himself, as well as authors he quote lament the fact that many developers do not take the time to read and study their own profession and history. I have no basis to say whether this is holds or not, however, if it is the case, this book is a good entertaining pick. Despite its age, it is just as relevant today.

If you are or have ever been part of a software project, either as a developer, designer, tester or manager, this book will come with a lot of deja vu moments. Every team believes to some extent that their project, their company, or their goal is special. And because it is special, conventional rules and wisdom does not hold. Usually, history tends to get the last laugh as it repeats itself over and over.