- STAFF PICKS
- GIFTS + GIFT CARDS
- SELL BOOKS
- FIND A STORE
This item may be
Check for Availability
Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Softwareby Scott Rosenberg
Synopses & Reviews
Michael Toy places his palms on his cheeks, digs his chin into his wrists, squints into his PowerBook, and begins the litany.
John is doomed. He has five hundred hours of work scheduled between now and the next release. . . . Katie's doomed. She has way more hours than there are in the universe. Brian is majorly doomed. Plus he's only half time. Andy--Andy is the only one who doesn't look doomed. There are no hundreds on his list.
They don't look doomed, these programmers sitting around a nondescript conference room table in Belmont, California, on a summer day. They listen quietly to their manager. Toy is a tall man with an impressive gut and a ponytail, but he seems to shrink into a space of dejection as he details how far behind schedule the programmers have fallen. It's July 17, 2003, and he's beginning to feel doomed himself about getting everything done in the less than two months before they are supposed to finish another working version of their project.
Everybody who has a list with more time than there is in the universe needs to sit down with me and go over it.
These lists are the bug lists--rosters of unsolved or open problems or flaws. Together they provide a full accounting of everything these software developers know must be fixed in their product. The bug lists live inside a program called Bugzilla. Toy's programmers are also using Bugzilla to track all the programming tasks that must be finished in order to complete a release of the project; each one is responsible for entering his or her list into Bugzilla along with an estimate of how long each task will take to complete.
Now let's talk about why we're behind. Does anyone have a story to tell?
There's silence for a minute. John Anderson, a lanky programming veteran whose title is systems architect and who is, in a de facto sort of way, the project's lead coder, finally speaks up, in a soft voice. There's a bunch of reasons. In order to build something, you have to have a blueprint. And we don't always have one. Then you hit unexpected problems. It's hard to know how long something's going to take until you know for sure you can build it.
But you can't just throw up your hands and say, I quit. Toy usually prefers to check things off his agenda fast, running his developers' meetings with a brisk attitude of let's get out of here as fast as we can that's popular among programmers. But today he's persistent. He won't let the scheduling problems drop. We need to make guesses and then figure out what went wrong with our guesses.
Jed Burgess, one of the project's younger programmers, speaks up. There's a compounding of uncertainty: Your estimates are based on someone else's estimates.
Toy begins reviewing Anderson's bugs. The famous flicker-free window resizing problem. What's up with that?
Officially, this was bug number 44 in Bugzilla, originally entered on January 19, 2003, and labeled Flicker Free window display when resizing windows. I had first heard of the flicker-free window resizing problem at a meeting in February 2003 when the Open Source Applications Foundation (OSAF), whose programmers Toy was managing, had completed the very earliest version of its
"Software is easy to make, except when you want it to do something new,' Rosenberg observes — but the catch is that 'the only software worth making is software that does something new.' This two-tiered insight comes from years of observing a team led by Mitch Kapor (the creator of the Lotus 1-2-3 spreadsheet) in its efforts to create a 'personal information manager' that can handle to-do lists as easily as events scheduling and address books. Rosenberg's fly-on-the-wall reporting deftly charts the course taken by Kapor's Open Source Applications Foundation, while acknowledging that every software programmer finds his or her own unique path to a brick wall in the development process. (The software is still in development even now.) With equal enthusiasm, Rosenberg digs into the history of the computer industry's efforts to make programming a more efficient process. Though there's a lot of technical information, it's presented in very accessible terms, primarily through the context of project management. Even readers whose computer expertise ends at retrieving their e-mail will be able to enjoy digressions into arcane subjects like object-oriented programming." Publishers Weekly (Copyright Reed Business Information, Inc.)
A noted journalist chronicles three years in the lives of a team of maverick software developers, led by Lotus 1-2-3 creator Mitch Kapor, intent on creating a revolutionary personal information manager to challenge Microsoft Outlook. 40,000 first printing.
Their story takes us through a maze of dead ends and exhilarating breakthroughs as they and their colleagues wrestle not only with the abstraction of code but with the unpredictability of human behavior,
especially their own. Along the way, we encounter black holes, turtles, snakes, dragons, axe-sharpening, and yak-shaving—and take a guided tour through the theories and methods, both brilliant and misguided, that litter the history of software development, from the famous “mythical man-month” to Extreme Programming. Not just for technophiles but for anyone captivated by the drama of invention, Dreaming in Code offers a window into both the information age and the workings of the human mind.
From the Hardcover edition.
Table of Contents
Ch. 0. Software time (1975-2000) — Ch. 1. Doomed (July 2003) — Ch. 2. The soul of agenda (1968-2001) — Ch. 3. Prototypes and Python (2001-November 2002) — Ch. 4. Lego Land (November 2002-August 2003) — Ch. 5. Managing dogs and geeks (April-August 2003) — Ch. 6. Getting design done (July-November 2003) — Ch. 7. Detail view (January-May 2004) — Ch. 8. Stickies on a whiteboard (June-October 2004) — Ch. 9. Methods — Ch. 10. Engineers and artists — Ch. 11. The road to dogfood (November 2004-November 2005) — Epilogue : A long bet (2005-2029 and beyond).
What Our Readers Are Saying
Business » General