- Shopping Bag ( 0 items )
"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.
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.
Posted September 19, 2009
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.
Posted March 23, 2009
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 NoThank you for your feedback. Report this reviewThank you, this review has been flagged.
Posted October 2, 2011
No text was provided for this review.
Posted July 12, 2010
No text was provided for this review.
Posted October 28, 2008
No text was provided for this review.