Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software


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 ...
See more details below
Paperback (Reprint)
BN.com price
(Save 12%)$15.00 List Price

Pick Up In Store

Reserve and pick up in 60 minutes at your local store

Other sellers (Paperback)
  • All (29) from $1.99   
  • New (10) from $8.25   
  • Used (19) from $1.99   
Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software

Available on NOOK devices and apps  
  • NOOK Devices
  • Samsung Galaxy Tab 4 NOOK 7.0
  • Samsung Galaxy Tab 4 NOOK 10.1
  • NOOK HD Tablet
  • NOOK HD+ Tablet
  • NOOK eReaders
  • NOOK Color
  • NOOK Tablet
  • Tablet/Phone
  • NOOK for Windows 8 Tablet
  • NOOK for iOS
  • NOOK for Android
  • NOOK Kids for iPad
  • PC/Mac
  • NOOK for Windows 8
  • NOOK for PC
  • NOOK for Mac
  • NOOK for Web

Want a NOOK? Explore Now

NOOK Book (eBook)
BN.com price


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.
Read More Show Less

Editorial Reviews

From Barnes & Noble
In software programming, as in every other form of human enterprise, it's relatively easy to move around the blocks; creating elegant new innovations is something else. Former Salon.com technology editor Scott Rosenberg knows all too well that much of life in 21st-century America hangs from fragile strands of computer code. In Dreaming in Code, he follows that slender connection back to the FBI, the FAA, and the IRS, each of which failed in costly recent attempts to build new software systems. In a fascinating case study, Rosenberg tracks Lotus 1-2-3 inventor Mitch Kapor and his crew as they attempt to mastermind a software device for day-to-day business functions. The material is technical but well presented, and the author never loses touch with his narrative.
From the Publisher
"Technology people like to call complicated problems 'nontrivial.' Scott Rosenberg has taken an extremely nontrivial topic and made it accessible. He plainly admires the people who create code, but shows them as the complex, flawed beings we all are- and how human talents, quirks and passions become part of what people create. Dreaming in Code is stellar reporting and writing."
–Dan Gillmor, Director, Center for Citizen Media and author of We the Media

"We live in a world increasingly governed by the near-invisible logic of software, and yet most of us know almost nothing about that hidden world inside our computers. Dreaming in Code is a fascinating and sobering exploration of how the challenges of programming both inspire and undermine our human drive to create new tools. Beautifully written, it's a book for anyone interested in the roots of creativity and innovation, for coders and non-coders alike."
–Steven Johnson, author of Everything Bad Is Good for You and Emergence

"The great software genius Bill Joy likes to say that writing software is like building a cathedral: It's art, science, architecture, and manual labor all rolled into one. Dreaming in Code illuminates the truth of that metaphor in all its subtlety and fullness. It has drama, comedy, pathos, and poignancy- and its center, in Mitch Kapor, is one of the most fascinating and yet least understood figures of the digital revolution. It's also so smart and insightful on its subject as any book I know."
–John Heilemann, New York Magazine columnist and author of Pride Before The Fall: Trials of Bill Gates and the End of the Microsoft Era

"Dreaming in Code is the first true successor to Tracy Kidder's Soul of a New Machine, and is written with a combination of technical sophistication and narrative skill not seen in many years. Read it to understand what all these software wizards actually do."
–James Fallos, The Atlantic

"Dreaming in Code bravely goes where no nonprogrammer has dared to go before: into the whirlwind where human imagination struggles to become code. Scott Rosenberg brilliantly interweaves the story of a start-up software company with the history of our (endless) attempts to rationalize the process of programming. He brings the reader close to the programmers: to root for them, then worry for them, as their project begins falling into all the old traps. Yet Rosenberg's admiration for the visionaries and coders shines through, until one almost believes they will one day succeed at creating their own 'Key To All Mythologies,' their repository of all things digital. Most people do not understand what goes into the creation of computer software, but now they will."
–Ellen Ullman, author of Close to the Machine: Technophilia and Its Discontents

From the Hardcover edition.

Publishers Weekly
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.
Library Journal
Salon.comcofounder Rosenberg asks, "Why is good software so hard to make?" and answers the question by telling the tale of a group of programmers using open-source software to create a "killer PIM (Personal Information Management) application." Throughout, he interweaves historical developments in programming languages, methods for writing and documenting code, project-management theories, and predictions for the future of programming. In addition, he introduces the reader to programming concepts and an amazing cast of characters from the past and present. Though anyone who has worked on a programming project will appreciate this educational and entertaining work, the subject is one that laypeople will also enjoy. An index and detailed notes for each chapter round out the volume and prove useful for those wanting more information. A good read; highly recommended for public and academic libraries.
—Colleen Cuddy
Read More Show Less

Product Details

  • ISBN-13: 9781400082476
  • Publisher: The Crown Publishing Group
  • Publication date: 2/26/2008
  • Edition description: Reprint
  • Pages: 416
  • Sales rank: 682,226
  • Product dimensions: 5.20 (w) x 8.00 (h) x 0.90 (d)

Read an Excerpt



[JULY 2003]

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. Now, nearly six months later, he still hasn't fixed it.

Today Anderson explains that the problem is thornier than he had realized. It isn't simply a matter of fixing code that he or his colleagues have written; its roots lie in a body of software called wxWidgets that the Chandler team has adopted as one of the building blocks of their project. Anderson must either wait for the programmers who run wxWidgets to fix their own code or find a way to work around their flaw.

"So you originally estimated that this would take four hours of work," Toy says. "That seems to have been off by an order of magnitude."

"It's like a treasure hunt," Anderson, unflappable, responds. "You have to find the first thing. You have to get the first clue before you're on your way, and you don't know how long it will take."

"So you originally estimated four hours on this bug. You now have eight hours."

"Sometimes," Anderson offers philosophically, "you just wake up in the morning, an idea pops into your head, and it's done--like that."

Mitchell Kapor has been sitting quietly during the exchange. Kapor is the founder and funder of the Open Source Applications Foundation, and Chandler is his baby. Now he looks up from his black Thinkpad. "Would it be useful to identify issues that have this treasure-hunt aspect? Is there a certain class of task that has this uncertainty?"

"Within the first hour of working on the bug," Burgess volunteers, "you know which it's going to be."

So it is agreed: Bugs that have a black hole-like quality--bugs that you couldn't even begin to say for sure how long they would take to fix--would be tagged in Bugzilla with a special warning label.

Shortly after the meeting, Toy sits down at his desk, calls up the Bugzilla screen, and enters a new keyword for bug number 44, "Flicker Free window display when resizing windows": scary.

Toy's fatalistic language wasn't just a quirk of personality: Gallows humor is a part of programming culture, and he picked up his particular vocabulary during his time at Netscape. Though today Netscape is remembered as the Web browser company whose software and stock touched off the Internet boom, its developers had always viewed themselves as a legion of the doomed, cursed with impossible deadlines and destined to fail.

There was, in truth, nothing especially doomed about OSAF's programmers: Several of them had just returned from a conference where they presented their work to an enthusiastic crowd of their peers--who told them that their vision could be "crisper" but who mostly looked at the blueprint for Chandler and said, "I want it now!" Though the software industry had been slumping for three straight years, they were working for a nonprofit organization funded by $5 million from Kapor. Their project was ambitious, but their ranks included veteran programmers with estimable achievements under their belts. Andy Hertzfeld had written central chunks of the original Macintosh operating system. John Anderson had written one of the first word processors for the Macintosh and later managed the software team at Steve Jobs's Next. Lou Montulli, another Chandler programmer who was not at the meeting, had written key parts of the Netscape browser. They'd all looked doom in the eye before.

Similarly, there was nothing especially scary about bug number 44. It was a routine sort of problem that programmers had accepted responsibility for ever since computer software had migrated from a text-only, one-line-at-a-time universe to today's graphic windows-and-mouse landscape. What scared Toy was not so much the nature of Bug 44 but the impossibility of knowing how long it would take to fix. Take one such unknown, place it next to all the other similar unknowns in Chandler, multiply them by one another, and you have the development manager's nightmare: a "black hole" in the schedule, a time chasm of indeterminate and perhaps unknowable dimensions.

Two months before, the entire Chandler team of a dozen programmers had met for a week of back-to-back meetings to try to solve a set of problems that they had dubbed "snakes"--another word Toy had salvaged from Netscape's ruins. A snake wasn't simply a difficult problem; it was an "important problem that we don't have consensus on how to attack." Snake superseded a looser usage at OSAF of the word dragon to describe the same phenomenon.

Black holes, snakes, dragons--the metaphors all daubed a layer of mythopoetic heroism over the most mundane of issues: how to schedule multiple programmers so that work actually got done. You could plug numbers into Bugzilla all day long; you could hold one meeting after another about improving the process. Software time remained a snake, and it seemed invincible.

This was hardly news to anyone in the room at OSAF. The peculiar resistance of software projects to routine scheduling is both notorious and widely accepted. In the software development world, lateness was so common that a new euphemism had to be invented for it: slippage.

Certainly, every field has its sagas of delay; the snail's pace of lawsuits is legendary, and any building contractor who actually finishes a job on time is met with stares of disbelief. But there's something stranger and more baffling about the way software time bends and twists back on itself like a Mobius strip. Progress seems to move in great spasms and then halt for no reason. You think you're almost done, and then you turn around and six months have passed with no measurable progress.

This is what it feels like: A wire is loose somewhere deep inside the workings. When it's connected, work moves quickly. When it's not, work halts. Everyone on the inside tries painstakingly to figure out which wire is loose, where the outage is, while observers on the outside try to offer helpful suggestions and then, losing their patience, give the whole thing a sharp kick.

Every software project in history has had its loose wires. Every effort to improve the making of software is an effort to keep them tight.

The earliest and best diagnosis of the problem of software time can be found in a 1975 book by Frederick Brooks, The Mythical Man-Month. Brooks was a veteran IBM programming manager who had seen firsthand the follies of the largest software project of its day, the creation of the operating system for the IBM System/360. That huge, expensive mainframe computer would become the mainstay of big business for the next two decades, but its gestation and birth were plagued with delays and cost overruns. It had become, as Brooks put it, a "tar pit," a sticky trap for corporate beasts, even ones as "great and powerful" as IBM. Brooks's group at IBM, confounded by how far behind they'd fallen, flung waves of new programmers at the job, like General Lee's ordering one brigade after another to charge up Cemetery Ridge--only to find that the reinforcements, far from getting the project over its hump, actually made things worse.

And so he formulated Brooks's Law, which is both a principle and a paradox: "Adding manpower to a late software project makes it later."

The soundness of Brooks's Law has been borne out over and over in the three decades since its formulation. But it is so deeply counterintuitive that it still regularly flummoxes programmers and managers, who often would rather pretend that it does not apply to them than deal with its disturbing implications.

Brooks noted that software developers are typically optimists who assume that each bug can be fixed quickly and that the number of new bugs will diminish until the last one has been licked. This optimism, along with the programmers' desire to please the impatient patrons who have commissioned them to create something new, skews the schedule from the start. In practice, Brooks found, nearly all software projects require only one-sixth of their time for the writing of code and fully half their schedule for testing and fixing bugs. But it was a rare project manager who actually planned to allocate developers' time according to such a breakdown.

Next, Brooks argued, the "very unit of effort used in estimating and scheduling" was "a dangerous and deceptive myth." The "man-month" was a concept of scientific management that assumed productivity could be broken down into discrete, identical, fungible units. So if one hundred men (in those days the gender assumption simply came with the territory) could produce fifty widgets in one month, then a single widget required two man-months--and you ought to be able to produce the same number of widgets sooner by throwing more workers at the project. Want your fifty widgets in three days instead of thirty? Just throw one thousand workers at the job instead of one hundred.

Brooks observed that "men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them." With software, where every project is different and the tools are in constant flux, each time you add a new member to a team, the veterans must drop what they are doing to bring the latecomer up to speed, and everyone needs to pause to reapportion their tasks to give the newcomer something to do. Before you know it, you're even further behind schedule. In the worst cases, Brooks saw, this set up a disastrous loop of delay, a "regenerative scheduling disaster" in which each resetting of the schedule triggers the hiring of more bodies, forcing yet another new schedule into place. Brooks quailed at that prospect: "Therein lies madness."

In any case, Brooks found that much of the work in creating software also suffers from "sequential constraints" that limit how far you can go in splitting up tasks: One task must be completed before the next can be tackled, regardless of how many hands work on it. "The bearing of a child takes nine months," he wrote, "no matter how many women are assigned."

Finally, the extreme variations in productivity from programmer to programmer--a great programmer was typically able to produce ten times as much work in a given amount of time as a mediocre one, and the work was typically five times as good (measured in terms of speed and efficiency)--sealed Brooks's case against the man-month. If one man's work was so drastically different from another's, that yardstick was useless.

Brooks's Law implies that the ideal size for a programming team is one--a single developer who never has to stop to communicate with a colleague. This approach streamlines everything, and it also provides insurance that the project will retain what Brooks calls "conceptual integrity": the alignment of all its parts toward the same purpose and according to a harmonious plan. Indeed, the history of software is full of breakthroughs made by lone wolves. But too much software has simply grown too huge for one person to produce--from the elaborateness of the graphic interface that make programs easier to use to the complexity of the data structures required to reliably and usefully store the huge volumes of information we trust our computers with.

From the Hardcover edition.

Read More Show Less

Table of Contents

Software Time [1975-2000]     1
Doomed [July 2003]     11
The Soul of Agenda [1968-2001]     32
Prototypes and Python [2001-November 2002]     56
Lego Land [November 2002-August 2003]     84
Managing Dogs and Geeks [April-August 2003]     116
Getting Design Done [July-November 2003]     145
Detail View [January-May 2004]     175
Stickies on a Whiteboard [June-October 2004]     208
Methods     236
Engineers and Artists     270
The Road to Dogfood [November 2004-November 2005]     310
Epilogue: A Long Bet [2005-2029 and Beyond]     346
Postscript to the Paperback Edition     356
Notes     362
Acknowledgments     389
Index     392
Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing all of 5 Customer Reviews
  • Posted September 19, 2009

    A Must Read for Technology Managers

    I feel like this book is a must read for anyone that will manage or be apart of any type of technology project. Specifically a software or web based application.

    A lot of the issues they mention in this book happens to a lot, if not all tech projects. They mention things like, how many programmers on a project is too much, at what point does adding more people to a project actually slow down the progress of the project, issues with documentation or lack off, too many meetings not enough work time, progress for progress sake, .. etc.

    The book is written like a story and not like someone lecturing you. The writer never states you should do x y z (from what I remember). He usually mentions the outcome of doing things a certain way. He also mentions historic events in tech history and incorporates them into what was currently happening at the company he was observing.

    I plan on reading it again and making it a Sunday read book. I read it on my commute to work, so I'm sure there is stuff I missed or glazed over on while trying to stay awake or while trying to ignore people.

    Was this review helpful? Yes  No   Report this review
  • Posted March 23, 2009

    A Book Needed for a Long Time

    I wish this book or one like it had been written ten or fifteen years ago. Based on a journalist's observation of a particular software project, this book summed up much of what I have seen, learned, or learned wrongly, as a lay person and administrator, though not a programmer, but with responsibility for participating in evaluating software. It has expanded my horizon about what can be expected from software engineering and programming in terms of projects, deadlines, and trade-offs about what you can get and what will work. Amid a mountain of hype about where the information age is taking us, this volume taught me, at least, some salutary lessons about how the information age is really created.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted October 2, 2011

    No text was provided for this review.

  • Anonymous

    Posted July 12, 2010

    No text was provided for this review.

  • Anonymous

    Posted October 28, 2008

    No text was provided for this review.

Sort by: Showing all of 5 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)