This book tells the story of the multi-year development of one piece of software, and in doing so, touches on the challenges that all software development faces. Why isn't software "engineering" more like regular engineering, with a fixed blueprints, relatively predictable costs and timeframes? What makes software so much harder to manage and execute than almost any other endeavor that human beings undertake?

The first half of the book follows several years of development of Chandler, an open source PIM application. They seem to make every mistake that a software team can - but what's interesting about this is almost every single software project ever begun makes these exact same mistakes.

The term software engineering is a misnomer in and of itself: it was proposed at a NATO software conference in the 60's as a hopeful moniker, something programmers could grow into. It didn't take long for that to be forgotten. Despite massive changes in hardware, software, and methodologies, the problems facing software development really have not changed one bit in the last thirty years.

It's my own opinion that agile development and the principles of simplified design that are emerging in the web 2.0 bubble may be somewhat of an answer to this. The book makes a nod to this, but seems doubtful if this will be a real solution over the long term. Time will tell.

This is probably the book's biggest weakness: I read it in early 2007, shortly after its release, and already some of the contents are a bit dated. The world of software moves so fast that anything written about it tends to be out of date in hardly any time at all. Of course, part of the point of the book is that the more things change, the more they stay the same. Chances are good that most software projects will still be running over time, over budget, and ending in ruin a decade from now.