Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software | 
 enlarge | Author: Scott Rosenberg
Publisher: Three Rivers Press
Category: Book
List Price: $13.95
Buy New: $6.49
You Save: $7.46 (53%)
New (38) Used (13) from $6.49
Avg. Customer Rating:  61 reviews
Sales Rank: 12911
Media: Paperback
Number Of Items: 1
Pages: 416
Shipping Weight (lbs): 0.6
Dimensions (in): 7.9 x 5.1 x 1
ISBN: 1400082471
Dewey Decimal Number: 650
EAN: 9781400082476
ASIN: 1400082471
Publication Date: February 26, 2008
Availability: Usually ships in 1-2 business days
Condition: Brand new, never opened
|
| Also Available In:
|
| Similar Items:
|
| Editorial Reviews:
Amazon.com
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 author 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
Product 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.
|
| Customer Reviews: Read 56 more reviews...
hard to catagorize but a worthwhile read June 26, 2008
1 out of 1 found this review helpful
i'm a sucker for any book on the margins between philosophy, social issues and computers, how and why they are shaping us and our communities.
this is kind of what the book is about.
to get a decent quick view of it, read chapter 10- engineers and artists, i think that the main points are on display here.
a few new words like dogfoodable.
a few new ideas i want to follow up on: leaking abstractions
it is a watchful eye on a software projection-chandler with the other eye on what it all means. why is interfacing people with machines hard? what is slippage and why it always happens? but basically a beginning analysis of why writing software poses some curious philosophic and practical issues.
i liked the book, a worthwhile read, look at chapter 10 and see if it warrants your time as well.
thanks for reading this review.
 Best book ever about what software development is REALLY like June 21, 2008
I just finished reading an amazing book: "Dreaming in Code" by Scott Rosenberg. Like many good, recent non-fiction books, it alternates between a specific narrative with colorful real people, and general background information. In this case, it's the story of Chandler, a personal information management tool, and the team who are building it, led by Mitch Kapor.
The general background explains far more about real, contemporary software, how it is built, and what it's all about, than anything I've read before. Everyone learning to be a software engineer, or who wants to understand what software engineers actually do, should read this book.
In only 355 pages, Rosenberg discusses, in clear language that's easy to follow, at least the following:
* What working on a software project in a team is like, the subjective experience
* Open software, and the "Cathedral vs. Baazar" concept
* Doug Englebart's ideas (very germane to Chandler)
* Famous software fiascoes
* Computer languages, especially Python and how it compares to others
* Reusable software, software libraries, build versus buy
* What "geek" really means
* CVS, Bugzilla, and Wikis
* Why user interfaces are so hard to design
* Dependencies between parts of a system and how they block work
* Release management and scheduling
* Specifications and their nature
* Layers of abstraction
* Scaffolding
* Code reviews
* WebDAV and CalDAV
* Microsoft FUD
* Requirements analysis
* Methodologies: waterfall, agile
* The gist of No Silver Bullet and The Mythical Man-Month
* Ruby on Rails
* Software engineering, its history and what it means
* Complexity
* Late binding
* Object-oriented programming
* Recursion
* The halting problem
The story of Chandler and the team is compelling and instructive. On page 173 of the book, he says: "By now, I know, any software developer reading this volume has likely thrown it across the room in despair, thinking, `Stop the madness! They're making every mistake in the book!'" I did indeed feel that way by page 173. Here's my sense of what went wrong, based on the account in the book:
* They did not have one architect (Brooks makes a very good point about why there should be a single person)
* They didn't work out the architecture in advance, and they went back and changed it many times
* They had a very flexible data concept/model, in which items change type frequently in a user-visible way, which they didn't work out until quite late
* They kept changing their mind about their UI substrate: wxWidgets? Mozilla internals?
* The software ecosystem changed around them after all those years, and using a Web UI now made sense, but it was too late for them
* They could not figure out what database technology to use (they finally decided not to use the Zope Object Database, although their reasons for that decision don't impress me)
* It was originally supposed to be peer-to-peer, but they could not figure out how to make that work, so they changed it to be server-based, a major change very late in the design
* They had to design a security model for all this
* It was all extensible, which is great but takes a lot of work to do right
* There were complicated semantic issues with sharing, "chain-sharing", etc. which were not worked out early.
* They wanted to have extensional and intensional collections, like iTunes, but also wanted to combine the two (the so-called "exclude Bob Marley" feature), which makes the semantics a lot harder
* Their internal terminology was inconsistent, symptomatic of a lack of architectural integrity
* They did serious requirement analysis only late in the project
* It was putatively open-source, but it was much too immature to really get outside developers involved
* They were too focused on doing "the right thing" instead of getting something out fast; see Gabriel's "Worse is Better" paper
* They released much too early, partly because of the glare of publicity due to Mitch Kapor's involvement
I see that they are still in "preview" releases. This has been going on for six years now! They have no projected release date for 1.0. It will be free, under the Apache license.
I have always wanted a good personal information manager, and a lot about Chandler looks very promising. Someday I may be a happy user. Right now, I think I'll wait until release 1.0.
I hope they have moved beyond the problems illustrated in the book and are running smoothly now. Kudos to the whole Chandler team for letting Rosenberg be so involved, being so honest with him, and letting him produce this unique, spectacular book.
Excellent story about the complexity of software development May 31, 2008
0 out of 1 found this review helpful
If you are interested in software development...read this book.
If you aren't interested in software development...read this book.
If you've always wondered why software development is such a tough thing to manage and predict completion...read this book.
Did I say that you should read this book? :)
The book is not a detailed "how to"...it is a story that follows the development of "Chandler", a software product that was going to 'change the world'....but of course, the product never really materialized. The team worked on the product for more than 5 years and never produced what the founder, Mitch Kapor of Lotus 1-2-3 fame, had envisioned. 5 years, over 4700 bugs and two dozen programmers with very little to show for the effort.
Take a look at the Related Articles below...you'll see that Chandler is just now coming to be a "1.0" release after 7 years of development. Interested story and a great book.
If you find yourself perplexed about the process of software development, this book might help you move a little closer to understanding the complexity of this process.
Definitely recommended reading.
 Depressing May 6, 2008
1 out of 3 found this review helpful
After the first chapter I was skeptical. After the second I was depressed.
This is the kind of humour that I imagine really motivates low level techies who assemble computers for a living and makes them feel superior to the entire world because they can plug in a video card. Remember the tech guy that insults you from "Saturday Night Live"? To be clear its intellectual arrogance about stuff that's not that intellectual.
This is the field I'm going to base my life's work on. I don't need to read how hard it is. I want to read about successful projects and how ppl coded great applications. I mistook this book for "Beautiful Code" which I'm guessing is a lot closer to something I'd like to read.
I wish I could send this book back but it was bought as a gift for me in an airport. Its seriously demotivating for an aspiring programmer and I imagine that the author is quite pompus for somone stating some pretty obvious stuff.
A pleasure to read April 11, 2008
0 out of 1 found this review helpful
Setting aside, for a moment, that the content of this book is interesting and helpful to programmers and non-programmers in understanding the trials and tribulations of software development, the main thing about this book that struck me is how very very nice it is to read on the Kindle. I've discovered that presentation and formatting still matter a good deal in electronic books, and Dreaming in Code does it right. It's a page-turner for the digital age, my bedtime story after a long day of bit-banging and code-monkeying.
|
|
|
