Dreaming In Code, by Scott Rosenberg

It's easy to see why Dreaming in Code has been such a hit. I just finished reading it and found it to be an extremely well written insider's look at a software development project.  Even if you're not that interested in the story behind the still unreleased Outlook killer, otherwise known as "Chandler", you'll find this to be a great overview of why the whole application/system development process can be so darned complicated.  In fact, you might find yourself wondering how any development team ever manages to get any product out the door!

Dreaming in Code is the story behind Mitch Kapor's latest dream of inventing a much better contact management tool than the world has ever seen before.  You can keep up with the team's progress via their website and blog, but if you're really curious and want to know the full history, you need to read the book as well.  There's also a companion website for the book at www.dreamingincode.com; it's full of great resources and an excellent example of how all book websites should be built.

Scott Rosenberg does a fantastic job of explaining the challenges, dilemmas, decisions and everything else that trips up most software development projects.  It took me back to my days, long ago, as a programmer writing code for point-of-sale systems at NCR in the 1980's.  It's funny (or maybe not so funny) how most of the same problems that plagued the teams I was part of  20 years ago still crop up on a regular basis today.  In fact, that's one of the more interesting aspects of this book and one that Rosenberg covers well by going back even further into the 1960's and IBM's System/360.

Here are a couple of excerpts that I found to be most insightful, the second of which is also quite relevant for those of us in the tech book publishing business:

Chandler was no different from the great majority of software projects.  It's rare for a group of software developers to work together on a series of projects over time; in this they are less like sports teams or military units or musical ensembles and more like the forces of pros who assemble to make a movie and then disperse and recombine for the next film.  So, while individual programmers and managers may carry with them a wealth of experience and knowledge of techniques that served them well in the past, each time they begin a new project with a new team, they are likely to end up pressing the reset button and having to devise a working process from first principles.

Joel Spolsky is quoted in the book and reports this about development methodologies:  ...the majority of developers don't read books about software development, they don't read web sites about software development, they don't even read Slashdot.  So they're never going to get this, no matter how much we keep writing about it.

What I liked best about this book though is that it's not just for programmers and other techies.  Rosenberg does a great job of writing everything in layman's terms so that even the most complex issue is readily understandable by all.  Read this book so that the next time your computer crashes or a new version of your favorite program has been delayed you'll have a better understanding of why it happened!

P.S. -- For anyone who cares, it's a little known fact that I came to the publishing world from the technology one.  I wrote code in Pascal, C and assembler for NCR from 1984 till 1990.  One of the two boxes I worked on, the NCR System 7000, was so long ago forgotten about that even Google can hardly find much about it.  The other one, the 2127 system, looks like this and is still in use in many grocery and drug stores.