I found the core story of of the non-development of Chandler, Mitch Kapor's PIM-on-steriods, to be mildly interesting. The project fizzled due to (a) too many different visions, (b) too many different ideas about architecture (c) too many people, (d) too much time, and (e) too much money. The first four are natural consequences of the last.
Chapters 9 and 10 divert from the story of Chandler to discuss software development in general. Great chapters, alone worth the price of the book. Rosenberg tours many of the key ideas, acronyms, books, essays, and people of the modern software movement: CMM, UML, XP, objects, The Cathedral the Bazaar, RubyOnRails, Open Source, Intentional, Leaky Abstractions, Hungarian, Agile, Spolsky, Ajax, 37 Signals, Kapor (obviously), Mythical Man Month, Dijkstra, Waterfall, Google, Alan Kay, Bill Joy, Knuth, Simonyi, Parnas, etc. etc. etc. Kudos to Rosenberg for smartly organized writing covering a lot of difficult terrain. The book runs up to early 2006, so it covers pretty recent technology. And the acknowledgements (p.386) provide list of software bloggers Rosenberg respects -- many of the names are familiar, but I'll certainly be checking out those new to me.
Rosenberg spends a few pages on 37 Signals. ("Constraints are your friend", "flexibility is overrated", "less software", "say 'no' by default", "find the right people", "don't build a half-assed product -- build half a product". Amen!) He describes how BaseCamp and RubyOnRails are largely the work one person, David Hansson. Rosenberg could have devoted more ink to the contrast between RoR (a unified vision of a single gifted programmer) and Chandler (too many visions, resulting in inertia and confusion.)
Many (all?) great pieces of software were born from the design a single individual, or from the design of a very small team. Emacs: At first Richard Stallman, later others. Linux: Torvalds, later others. Rails: Hansson, later others. TeX: Knuth, later others. Mathematica: Wolfram, later others. This list of examples is long. Small teams of great developers can move mountains.
James Fallows compares Dreaming in Code to Kidder's Soul of a New Machine (highly recommended). I wouldn't go quite that far, but the book is certainly worth a read if you're interested in the software development process.