Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Other Sellers on Amazon
+ $3.99 shipping
+ $3.99 shipping
Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software Hardcover – January 16, 2007
"Children of Blood and Bone"
Tomi Adeyemi conjures a stunning world of dark magic and danger in her West African-inspired fantasy debut. Learn more
Frequently bought together
Customers who viewed this item also viewed
Customers who bought this item also bought
In the 80s, Tracy Kidder's The Soul of a New Machine attempted to define the story of the development of a minicomputer: from the new science to the business and nascent culture of electronic hardware and software that was characteristic of that time. Scott Rosenberg's Dreaming in Code draws on Kidder's model as it attempts to document the state of software, the Internet, and everything circa 2006 through the lens of Chandler, an as-yet-unfinished software application for the management of personal information.
The Chandler project--driven by Mitch Kapor, the founder of Lotus Development and main designer of its 1-2-3 spreadsheet, and later co-founder of the Electronic Frontier Foundation--isn't the primary point of Dreaming in Code, though reading about software people and their social behavior is at least as interesting as reading about that of meerkats or monkeys. Rather, Chandler is a rhetorical device with which Rosenberg takes on the big questions: How do software development teams work (or not)? Why does the reuse of software modules rarely work altogether correctly? Does open-source development by volunteers on the Internet lead to innovation or just insanely bifurcated chaos? Chandler helps his readers think more clearly about all of these issues; however, "answers" to these questions are, of course, not to be had, which is one of his points.
The problem with books about technical subjects that aspire to appeal to a general audience, particularly computers and software, is that such subjects are so far outside the realm of familiarity of most people that the prose bogs down in analogy and metaphor. Rosenberg manages to avoid too much of that and deliver a readable account of software development and culture. --David Wall
From 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 © Reed Business Information, a division of Reed Elsevier Inc. All rights reserved.
Author interviews, book reviews, editors picks, and more. Read it now
Top customer reviews
There was a problem filtering reviews right now. Please try again later.
Where Rosenberg went wrong, unfortunately, is his choice of project to follow. Mitch Kapor's Chandler is quite atypical of software projects: it's driven entirely by one man's quixotic vision, and never has to encounter the usual give-and-take with VC's or upper management that help to clarify a plan. Kapor comes off as an untethered idealist (Al Gore makes the obligatory cameo at the office), and his project is afflicted by the same we-are-the-world unseriousness as his politics. Most notably, Kapor decides there should be no central repository for data (because, hey, down with authority and all that): instead, every item will just be represented, Napster-style, across users' personal computers. It's a costly decision that I don't think would have been made if it were more than just Kapor running the show.
Actually, I think the strongest part of the book is when Rosenberg abandons the project entirely in the middle section to delve into the history of the programming discipline, noting everyone from Donald Knuth to 37signals' Jason Fried. It's a useful, lucid introduction to the field that contains stories I hadn't seen before.
To pick some nits, there are errors that betray Rosenberg as an outsider. "Foo" and "bar", for instance, usually aren't stand-ins for variable names, they're stand-ins for *values*; variable names are decided on almost immediately once the need for one becomes known. [UPDATE: this caused some controversy in the comments. It's true that "foo" and "bar" can also represent variables, but I still contend that it's only in theoretical discussions, when nothing is known about those variables. The book (p. 196) calls them "placeholders" during real-life coding, which I don't think is often true. FURTHER UPDATE, AFTER MORE COMMENTS: Okay, okay, I guess I was wrong. You guys win!] Rosenberg also, I think, makes too big a deal of software's need for precise language: many other engineering fields, and the legal profession, require precise writing, with small errors potentially leading to catastrophe. Rosenberg also overreaches when trying his hand at software philosophy, declaring "The only software worth making is software that does something new" (tell that to the OpenOffice people).
All that aside, this is an entertaining book with some interesting insights, and it would be a great read for anyone who's thinking of going into programming - hopefully it won't scare them off.
Scott Rosenberg 2007
The basic theme, or at least the framework, of Scott Rosenberg's "Dreaming in Code" is an attempt by Mitch Kapor (of Lotus 1-2-3 fame) to develop a new software product, a sort of universal information manager (combo email / calendar / everything else) designated "Chandler". To do this, Kapor starts up OSAF, the Open Source Applications Foundation, and the initial plan is to develop it as an open source project, where there will be a core of dedicated programmers, paid and volunteer, but also a large on-line community with access to the source code who will kibitz and make contributions.
Initially, I found "Dreaming" less than compelling for a couple of reasons. First, I just can't get that enthusiastic about Chandler. Sure, there are some interesting design and coding problems, but the end product rates a big "eh" on my scale. Maybe I've just never operated in the right environment, where it's crucial that my calendar on my computer is magically synchronized with my wife's on her computer at her job, and with both of our home computers. A convenience, perhaps, but a major paradigm change, hardly. And second, none of the characters, the personalities and their interaction, grabbed my interest, either for their presence at OSAF or their outside life (did any even have an outside life?).
But after a few chapters, another theme developed: I found Rosenberg's reporting on the general history and philosophy of software development to be much more interesting and dynamic than the particular example on which he hung it. I've seen a good bit of this stuff before, but there was also much new to me and everything was put neatly in a historical frame (sometimes amusingly so, as when a litany of woes that sounds very contemporary was revealed to be from the 1960's or even 50's). The usual questions are brought up -- Why is writing software so hard? Why can't simple "leggo blocks" be developed which can then be snapped together without costly hand-crafting? Why can't we really "engineer" software in the sense that we can a bridge or a toaster oven? Why is it so hard for groups to work together on large software projects, to develop and keep to realistic schedules? Rosenberg doesn't provide any definitive answers, because no one else has, but he does describe many attempts to do so. And as the general theme develops, the example of Chandler itself becomes more interesting, even exciting.
The book overall is well and pithily written ("it's schedule would evolve (read: lengthen) as necessary."), and Rosenberg is obviously well read and has integrated a great deal of material on software engineering as well as observed closely the Chandler project for several years (as of the writing, Chandler was barely beginning to put togther a usable but restricted version). There are a few errors, or at least misdirections, just enough to remind us that the author is not himself a programmer or techie. E.g., on p 239, his description of the GOTO statement (as in Djikstra's "GOTO Considered Harmful") and spaghetti code is misleading: "[GOTO] handed off control from one point in a program to another unconditionally, taking nothing else into account -- neither the values of different variables nor the state of the program and its data." Of course even in the era of 1960's Fortran, which Rosenberg invokes, the naked GOTO was relatively uncommon in higher level languages. [In assembly coding, where shifting existing code to insert an extra line could cause problems, 'patches' were often just placed somewhere else, with GOTO's leading to and from them.] More commonly it would be combined with a conditional statement specifically to take into account the "values of different variables", such as A and B here:
IF (A.LT.B) GOTO 275
[ if A is less than B, then jump to a statement labelled 275 and proceed from there ]
A seemingly naked GOT might appear when combined with this to form a "roll your own" IF..THEN..ELSE.. structure:
IF (A.LT.B) GOTO 100
<do some stuff>
100 <do some other stuff>
110 <continue with rest of program>
Of course such branching can lead to very confusing jumbles of code unless the programmer makes an effort at structure, clarity and commenting.
If my recollection is correct (and I began programming with Fortran and Algol in the mid 60's), the above was about the only form of branching available in the earliest Fortran, but certainly by the late 60's programmers had less easily abused control statements such as IF..THEN..ELSE, as well as the functions and subroutines that had been used since the beginning or near it. Djikstra's shocking 1968 proposal was that programmers should be limited to a carefully defined set of such 'structured' tools, and the simple GOTO (who the heck knows what or where statement 275 is in the above example?) totally abandoned.
Overall, an excellent book for its history and observations on software development and its problems. I'd give those parts alone 5*, or maybe 4.5* for the occasional statement that seems a bit off, but because the story of Chandler and OSAF itself was mostly pretty dull, or at least unmotivated, to me, I'll knock it down to 4*. If office desktop managers really perk you up, you may enjoy it more fully than I did.