Our civilization runs on software. Yet the art of creating it continues to be a dark mystery, even to the experts. To find out why it’s so hard to bend computers to our will, Scott Rosenberg spent three years following a team of maverick software developers—led by Lotus 1-2-3 creator Mitch Kapor—designing a novel personal information manager meant to challenge market leader Microsoft Outlook. Their story takes us through a maze of abrupt
dead ends and exhilarating breakthroughs as they wrestle not only with the abstraction of code, but with the unpredictability of human behavior— especially their own.
In the 80s, Tracy Kidder's The Soul of a New Machine attempted to define the story of the development of a minicomputer: from the new science to the business and nascent culture of electronic hardware and software that was characteristic of that time. Scott Rosenberg's Dreaming in Code draws on Kidder's model as it attempts to document the state of software, the Internet, and everything circa 2006 through the lens of Chandler, an as-yet-unfinished software application for the management of personal information. The Chandler project--driven by Mitch Kapor, the founder of Lotus Development and main author of its 1-2-3 spreadsheet, and later co-founder of the Electronic Frontier Foundation--isn't the primary point of Dreaming in Code, though reading about software people and their social behavior is at least as interesting as reading about that of meerkats or monkeys. Rather, Chandler is a rhetorical device with which Rosenberg takes on the big questions: How do software development teams work (or not)? Why does the reuse of software modules rarely work altogether correctly? Does open-source development by volunteers on the Internet lead to innovation or just insanely bifurcated chaos? Chandler helps his readers think more clearly about all of these issues; however, "answers" to these questions are, of course, not to be had, which is one of his points. The problem with books about technical subjects that aspire to appeal to a general audience, particularly computers and software, is that such subjects are so far outside the realm of familiarity of most people that the prose bogs down in analogy and metaphor. Rosenberg manages to avoid too much of that and deliver a readable account of software development and culture. --David Wall
Author: Scott Rosenberg
Publisher: Three Rivers Press
Customer Reviews
-
Best behind-the-scenes book since "Hackers"
I've not enjoyed a book this much since I read Steven Levy's "Hackers" - the behind-the-scenes stories and discussions are just great. I'm not a programmer by trade, but I dabbled a bit in high school and got some more in-depth training in college, but it wasn't my major... a book like this makes me realize not only the fun I may have missed but also the stress I may have dodged. The book definitely provides the ups and downs of the software development business. I especially enjoyed getting a deeper understanding of the Open Source movement and discovering that it too has its built-in problems and isn't the wonder-tech that some books and articles might try to paint it.
<br />
<br />The best part of the book was reading along with each release of Chandler... .4 then .5 then .6... and now I visit the actual website and see that they did make their 1.0 release! The book just made my investigation of the actual product and its support/help/website that much more fun.
<br />
<br />Great book! I'd love to see similar books done like this down the line.
<br />
<br />
-
Best book ever about what software development is REALLY like
<br />I just finished reading an amazing book: "Dreaming in Code" by Scott Rosenberg. Like many good, recent non-fiction books, it alternates between a specific narrative with colorful real people, and general background information. In this case, it's the story of Chandler, a personal information management tool, and the team who are building it, led by Mitch Kapor.
<br />
<br />The general background explains far more about real, contemporary software, how it is built, and what it's all about, than anything I've read before. Everyone learning to be a software engineer, or who wants to understand what software engineers actually do, should read this book.
<br />
<br />In only 355 pages, Rosenberg discusses, in clear language that's easy to follow, at least the following:
<br />
<br /> * What working on a software project in a team is like, the subjective experience
<br /> * Open software, and the "Cathedral vs. Baazar" concept
<br /> * Doug Englebart's ideas (very germane to Chandler)
<br /> * Famous software fiascoes
<br /> * Computer languages, especially Python and how it compares to others
<br /> * Reusable software, software libraries, build versus buy
<br /> * What "geek" really means
<br /> * CVS, Bugzilla, and Wikis
<br /> * Why user interfaces are so hard to design
<br /> * Dependencies between parts of a system and how they block work
<br /> * Release management and scheduling
<br /> * Specifications and their nature
<br /> * Layers of abstraction
<br /> * Scaffolding
<br /> * Code reviews
<br /> * WebDAV and CalDAV
<br /> * Microsoft FUD
<br /> * Requirements analysis
<br /> * Methodologies: waterfall, agile
<br /> * The gist of No Silver Bullet and The Mythical Man-Month
<br /> * Ruby on Rails
<br /> * Software engineering, its history and what it means
<br /> * Complexity
<br /> * Late binding
<br /> * Object-oriented programming
<br /> * Recursion
<br /> * The halting problem
<br />
<br />The story of Chandler and the team is compelling and instructive. On page 173 of the book, he says: "By now, I know, any software developer reading this volume has likely thrown it across the room in despair, thinking, `Stop the madness! They're making every mistake in the book!'" I did indeed feel that way by page 173. Here's my sense of what went wrong, based on the account in the book:
<br />
<br /> * They did not have one architect (Brooks makes a very good point about why there should be a single person)
<br /> * They didn't work out the architecture in advance, and they went back and changed it many times
<br /> * They had a very flexible data concept/model, in which items change type frequently in a user-visible way, which they didn't work out until quite late
<br /> * They kept changing their mind about their UI substrate: wxWidgets? Mozilla internals?
<br /> * The software ecosystem changed around them after all those years, and using a Web UI now made sense, but it was too late for them
<br /> * They could not figure out what database technology to use (they finally decided not to use the Zope Object Database, although their reasons for that decision don't impress me)
<br /> * It was originally supposed to be peer-to-peer, but they could not figure out how to make that work, so they changed it to be server-based, a major change very late in the design
<br /> * They had to design a security model for all this
<br /> * It was all extensible, which is great but takes a lot of work to do right
<br /> * There were complicated semantic issues with sharing, "chain-sharing", etc. which were not worked out early.
<br /> * They wanted to have extensional and intensional collections, like iTunes, but also wanted to combine the two (the so-called "exclude Bob Marley" feature), which makes the semantics a lot harder
<br /> * Their internal terminology was inconsistent, symptomatic of a lack of architectural integrity
<br /> * They did serious requirement analysis only late in the project
<br /> * It was putatively open-source, but it was much too immature to really get outside developers involved
<br /> * They were too focused on doing "the right thing" instead of getting something out fast; see Gabriel's "Worse is Better" paper
<br /> * They released much too early, partly because of the glare of publicity due to Mitch Kapor's involvement
<br />
<br />I see that they are still in "preview" releases. This has been going on for six years now! They have no projected release date for 1.0. It will be free, under the Apache license.
<br />
<br />I have always wanted a good personal information manager, and a lot about Chandler looks very promising. Someday I may be a happy user. Right now, I think I'll wait until release 1.0.
<br />
<br />I hope they have moved beyond the problems illustrated in the book and are running smoothly now. Kudos to the whole Chandler team for letting Rosenberg be so involved, being so honest with him, and letting him produce this unique, spectacular book.
<br />
-
Excellent story about the complexity of software development
If you are interested in software development...read this book.
<br />
<br />If you aren't interested in software development...read this book.
<br />
<br />If you've always wondered why software development is such a tough thing to manage and predict completion...read this book.
<br />
<br />Did I say that you should read this book? :)
<br />
<br />The book is not a detailed "how to"...it is a story that follows the development of "Chandler", a software product that was going to 'change the world'....but of course, the product never really materialized. The team worked on the product for more than 5 years and never produced what the founder, Mitch Kapor of Lotus 1-2-3 fame, had envisioned. 5 years, over 4700 bugs and two dozen programmers with very little to show for the effort.
<br />
<br />Take a look at the Related Articles below...you'll see that Chandler is just now coming to be a "1.0" release after 7 years of development. Interested story and a great book.
<br />
<br />If you find yourself perplexed about the process of software development, this book might help you move a little closer to understanding the complexity of this process.
<br />
<br />Definitely recommended reading.
|
