Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software by Scott Rosenberg (PDF)

Description

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.

User’s Reviews

Editorial Reviews: Review “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 About the Author Scott Rosenberg is a writer and editor who started making web pages in 1994 as an editor of the San Francisco Free Press and as a co-founder of Salon in 1995, where he was both a technology and managing editor. He began blogging in 2002, and is currently a contributor to Backchannel, Steven Levy’s technology-focused publication. His book, Say Everything: How Blogging Began, What It’s Becoming, and Why It Matters, tells the story of blogging. His follow-up, Dreaming in Code, discusses software development and its discontents. Excerpt. © Reprinted by permission. All rights reserved. CHAPTER 1DOOMED[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. Read more

Reviews from Amazon users which were colected at the time this book was published on the website:

⭐This book is likely to be of interest to developers and systems professionals, as well as a few others who are really interested in software development but don’t participate in it actively. This latter group is the luckier one: for the rest of us, watching this train wreck in slow motion is painful and frequently exasperating.There are two distinct matters to be discussed here: 1) the principle story of the book, and 2) how the subject matter is delivered.The principle story of the book is Chandler, a Personal Information Manager(PIM)/Groupware-type software that was conceived and developed as an open-source project. The project was abandoned after several years’ effort without having achieved its defining goals, and Dreaming is a narrative of the first few years.The blame for the failure must be place squarely at feet of the project’s founder and chief evangelist, Mitch Kapor. Mr. Kapor was the heroic developer of Lotus 1-2-3. For the growing number of you who have no idea what that was, it was the one app that made a PC worth having in the late 80s. It was the killer app for a long time.Chandler was meant to be Kapor’s extension of a PIM product that had once shown some promise at Lotus. He had the lofty idea of making this system capable of tying together all of the elements of PIM practice (calendar, task list, email, notes) into a seamless, ephemeral whole, without storage dictated by data type, and by the way, open source. Get it? Well, nobody else did either.This project failed because its goal could not and cannot be articulated in a short sentence. It was consistently defined by its desired attributes, without the faintest idea of how it could be achieved. In fact, when examined more closely the defining attributes seemed to be in direct contradiction to each other.If you will forgive me, the situation reminded me a lot of the health care bill of 2010. It was just forever before there ever was a bill. For at least two years, it existed as list of lofty attributes. For the few brief moments between the time it actually became a bill and the time it was passed into law, the Speaker of the House famously noted that we have to pass it to see what’s in it. But when it was finally dissected, it contained a number of conflicting requirements that could not live together successfully.And so it was with Chandler. I marvel at the fact that in the august collection of software professionals, no one at any point pitched a fit that the project had no clearly articulated mission, that they had not a clear image of what they were building, and how such building would occur. I presume it is because that in this particular open-source project, the developers were getting paid.The open source idea was intended to harness the executional capacity of the masses, but again, the project was too ethereal for the masses to work on. There was no unifying mantra, such as “Write a free Unix!” or “Replace IIS!”, for the masses to recite in unison. A candidate cry might have been “Replace Outlook!”, but Chandler was meant to be so much *more* than Outlook. Unfortunately, “Transcend Outlook!” just never caught on. So Kapor paid a number of available systems development heavy hitters to develop the open-source project. Most of them moved along to other pastures once they saw that the emperor was in fact naked.And all of that is pity, but again, the greater pity is that the disaster could not have been averted by a well-placed person pulling the emergency brake. In my experience in software development, you have a problem on your hands if your programmers start out by designing the splash screen. Similarly, that the software was named after the dog, the dog after the author, and the releases after the setting of the author’s stories just makes me want to puke. Perhaps we could get the cart and the horse in the right order.***A number of reviewers of this book have noted that the book is just as unfocused and wandering as the software project, and that is true. It isn’t entirely clear to me how it could have been otherwise, and moreover, it does not render the book unuseful. The father Berenstein Bear made an industry of showing the little tyke bear what not to do. Well, same here. Plus, the wandering captures the spirit of the endeavor.What I do not sufficiently hear in the review-o-sphere is the dramatic turn the book makes at chapter 9, into the history of software development methodologies and personalities. For 75 pages (a bit less than a quarter of the book), we get a fine tour of software craftsmanship over the decades. Along the way, every major title in software development (and not a few minor ones) is cataloged and discussed. This discussion and the attendant bibliography is easily worth the price of the book (and maybe worth the cost of reading the other 75% of the book),One issue the author had was when to stop the book, as the software never came to any cohesive point. So it just stopped, just like the software project did a couple of years later.I think the title was a poor choice. It has nothing whatever to do with the book except a tangential reference, and a great opportunity to say something conclusive about the project was lost. I suppose that the jury had not yet completely returned on the project when the book went to press, however, “The Road to Nowhere: Hazards of Following the Pied Piper” or “Good Money After Bad: How and Idea, a Bucket of Money, and a Dynamic Personality Weren’t Enough,” would have been a lot more on point.

⭐”Dreaming on Code” are two books mixed together into one. One of the books is the observation of the author of a multi-year high-profile software development project. The project eventually failed, but that wasn’t clear yet at the end of the book. The second book is the authors search for better ways of developing software. The book is structured as a few pages about the development project and a few pages of exploration.For me, the book about the software project was the most interesting. The project is called Chandler done by a company called Open Source Applications Foundation (OSAF) by Mitch Kapor (the founder of Lotus). It’s vision is to develop the next generation personal information manager (PIM), which is basically a calendar, email and note-maker integrated in one product. Chandler had a large investment and attracted some high-profile developers. Scott Rosenberg followed the Chandler project over a couple of years and the book describes his observations or narrative of the project.The Chandler project is fascinating as they aim to do things different… and end up making all the mistakes of traditional software projects. They want to get something out quickly and facilitate an open source community to build up the product. They end-up over-designing, late delivering and over-complicating the whole project. It is really painful to follow the project (at least for me) as I could see them make the mistakes and would want to say “nooo!” but they did it anyways. Eventually the book ends without knowing the end of Chandler, but if you search online you’ll discover that it unfortunately never delivered its vision.The second book is the authors search for delivering better software. He basically picks a theme and describes that and explains some of the history. For example, at some point it explains what open source is and how open source was created. Similarly, it explains lots of aspects of software development. Most of these ought to be nothing new for nearly any software developer… and it suggests the book is actually targeted to people who aren’t directly involved in software development but are curious about how it would work. The explorations were interesting but purposefully shallow, which made them a bit boring for me. Usually I ended up reading through them and wanting to go back to the Chandler project story to know what would happen there.All in all, the book was well written. I enjoyed the Chandler parts a lot (4 stars) and felt the explorations were just ok (3 stars). I decided to average it out to 3 stars, especially for software developers who probably know all the explorations already. 4 stars for people who are interested in discovering more about software development. A pretty ok book.

⭐An interesting read. As a software developer it’s interesting to read how other people go about it.A bit scrappy and could have done with a tougher editor.As its a few years old events have over taken the project. The author speculates something Great! might still come from the project. Sadly history wasn’t kind.

⭐Despite it being dated every programmer (and manager of programmers) should read this book. The main truths about software development have not changed.

⭐A must read for developers

⭐…but rather stodgy in places.Tells the story of software development in the “good old days” before programming became a science rather than an art.

⭐Really interesting for a software developer to read

Keywords

Free Download Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software in PDF format
Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software PDF Free Download
Download Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software 2008 PDF Free
Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software 2008 PDF Free Download
Download Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software PDF
Free Download Ebook Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software