Zeros, Ones, And Headaches
DREAMING IN CODE Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software
DREAMING IN CODE
Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software
By Scott Rosenberg
Crown -- 400pp -- $25.95
The Good A fascinating look inside one software-development project.
The Bad The project has not yet been completed--and the book seems a tad unfinished, too.
The Bottom Line A worthwhile examination of how the sausage gets made.
Do you ever wonder why it took Microsoft Corp. (MSFT ) more than five years to deliver Windows Vista, the latest version of its PC operating system? Are you baffled that some software products lack the one feature that would make them so much simpler? Have you had it with programs crashing? These are some of the mysteries of software, which is simultaneously an amazing boon for humankind and one of its scourges.
To better understand such matters, take a look at Scott Rosenberg's Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software. The volume is a fascinating, yet ultimately frustrating, look inside one software-development project.
Rosenberg, co-founder of the online magazine Salon.com, knows his subject. He began tinkering with code in 1975 when, as a 15-year-old, he was given access to a New York University computer. Twenty-five years and many lines of code later, as managing editor of Salon.com, he experienced the frustrations of publishing a magazine with Web software. His tussles with programs made him want to better understand the process of software development. He decided to track the course of a single software project and tell its story.
For his target, Rosenberg chose Chandler, a project organized by PC industry pioneer Mitch Kapor. Kapor founded Lotus Development Corp. (IBM ), which published the first killer app of the PC era, the Lotus 1-2-3 spreadsheet. A true free spirit, Kapor dropped out of Lotus when it became big and bureaucratic, tried his hand at venture capital, and then settled in as a champion of online civil liberties and open-source software. Chandler, named after Raymond Chandler, the detective-novel author, began as an effort to invent a better electronic calendar--one that was easy to use, easy to share, and available on a variety of computers. Such a goal might seem simple and straightforward. Not so here: Although formal work on the project began in 2002, there is no end in sight. The "preview" version of Chandler is expected to be launched in the spring of 2007.
Why has development taken so long? Several reasons: Along the way, Kapor and his compatriots at the Open Source Applications Foundation decided to expand the functions in Chandler to include e-mail, task, and project management as well as group collaboration. This, in the parlance of the software industry, is called "feature creep" and is as common as it is irresistible. Second, technology changed, another common occurrence. Chandler started off as a program that would run on your PC and connect with others via peer-to-peer networking technology. As the project evolved, its designers added a server program to aid in the sharing of data and an online version called Scooby. And finally, figuring out how to build a new program, and then building it right, is just plain hard.
Rosenberg takes the reader inside the process to experience its joys and irritations. His scenes are vivid: In conference rooms in San Francisco and Belmont, Calif., we see celebrated software programmers of the PC era fill whiteboards with scribbling as they struggle over the large and small challenges involved in making something useful out of millions of zeros and ones. The cast of characters includes Andy Hertzfeld, a key member of the original Apple (AAPL ) Macintosh development team; Lou Montulli, a Web browser pioneer; and John Anderson, who managed software development for Steven P. Jobs's NeXT Software Inc. While these scenes may lack high drama, there's plenty of tension. As the project drags on, key programmers and managers quit in frustration, and Kapor's patience is frayed. Meanwhile, some journalists and even members of the open-source community write the project off as a lost cause.
In a sense, Rosenberg bailed as well. Under deadline pressure from his publisher, he sat down to write the book even though the project had not been completed. "My story's threads," he says, "were beginning to vanish into a software time black hole." Rosenberg says that he felt he had experienced enough to give a true picture of how software is made. But to the reader who longs for resolution, that's not altogether satisfying.
Toward the end, the author waxes profound, comparing software creators to Sisyphus, the Greek hero condemned to endlessly roll a boulder up a mountain. However apt the analogy, Rosenberg does not believe software-making is an exercise in futility. There's pleasure in it, and eventually most software gets shipped. Someday, presumably, a final version of Chandler will, too.
By Steve Hamm