Dreaming in Code - The longest software suicide note in history

I have only read up to page 50 of Dreaming In Code, but from bitter experience I already know what the eventual outcome will be.

Here are the lessons that should not be taken from the Chandler fiasco:

Software is hard. No it isn't. Thinking about writing software is easy. Writing software is easy. The hard part is actually delivering the software.

Design by consensus is good. "I'd like to teach the world to sing, in perfect harmony" may make a great Coke ad, but it's the road to hell on any software project. You definitely need a team to deliver software, but the vision and design should be clearly owned by one person. If it's too hard for one person to hold the design in their head and understand the implications of changes to that design, then how do you expect a normal human being to be able to use the bloody thing.

Big Design Up Front. Think very hard about what you want to do, and why your users want you to do it. Write a few dozen user stories and put them up on a wall. Then deliver those user stories, one at a time. Remember agile principle number one: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

The bottom line is this: Buy the book and read it, but don't expect to be seeing Chandler on a PC near you unless your watching old re-runs of Friends.

Chandler 0.7

Chandler 1.0

Chandler 1.1

Perhaps Chandler needed something like this at the beginning of their project:

It's interesting to note that after Andy Hertzfeld left Chandler to write his book he then went to work at Google.