Dreaming in Code : Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software
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.
"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. (Jan.) Copyright 2006 Reed Business Information. -- PUBLISHERS WEEKLY.
There are no customer reviews available at this time. Would you like to write a review?
January 15, 2007
Number of Print Pages*
Adobe DRM EPUB
* Number of eBook pages may differ. Click here for more information.
Excerpt from Dreaming in Code by Scott Rosenberg
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 project, Chandler--an internal release not for public unveiling that came even before the 0.1 edition. Ultimately, Chandler was supposed to grow up into a powerful "personal information manager" (PIM) for organizing and sharing calendars, email, to-do lists, and all the other stray information in our lives. Right now, the program remained barely embryonic.
At that February meeting, Anderson had briefly mentioned the flicker bug--when you changed the size of a window on the Chandler screen, everything flashed for a second--as a minor matter, something he wanted to investigate and resolve because, though it did not stop the program from working, it offended him aesthetically.