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

Rate this book

Clear rating

1 of 5 stars 2 of 5 stars 3 of 5 stars 4 of 5 stars 5 of 5 stars

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

3.59 of 5 stars 3.59 · rating details · 877 ratings · 144 reviews

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 leade...more

Paperback, 416 pages

Published February 26th 2008 by Three Rivers Press (first published January 16th 2007)

more details... edit details

Get a copy:

More…

Friend Reviews

To see what your friends thought of this book, please sign up.

Lists with This Book

This book is not yet featured on Listopia. Add this book to your favorite list »

Community Reviews

(showing 1-30 of 1,848)

filter | sort: default (?) | rating details

May 03, 2009 Eric_W rated it 4 of 5 stars

Shelves: technology

As CIO at a small college, I had the distinct unpleasure of signing purchase orders for software license renewals and maintenance contracts. In what other business would you buy a product that costs enormous sums of money, is guaranteed to be flawed, will require frequent and costly upgrades, never lives up to its promises, and requires a team of lawyers to interpret the contract, not to mention days of very expensive training for your staff. Welcome to the world of software.

Rosenberg follows th...more As CIO at a small college, I had the distinct unpleasure of signing purchase orders for software license renewals and maintenance contracts. In what other business would you buy a product that costs enormous sums of money, is guaranteed to be flawed, will require frequent and costly upgrades, never lives up to its promises, and requires a team of lawyers to interpret the contract, not to mention days of very expensive training for your staff. Welcome to the world of software.

Rosenberg follows the progress of the development of a software package from idea through development and debugging to end (actually, there is no end and to my knowledge they are still trying to come up with a workable product that may have already been superseded by others.). A major difficulty of development is getting many hundreds of programmers to work together and integrate their work into a cohesive product. Not to mention major resdeisgns in the middle of the project - try that with a bridge. The section on learning how to manage the project is worth the cost of the book. Programmers are well known for spending as much time designing the tools to help them use the tools and to save them time using the tools to work on the project than on the code itself.

"But in much of the business world today there lies, beneath the wide dissatisfaction with how software projects perform, a deeper anxiety—a fear that the root of the problem may lie not in failures of management technique but in the very nature of the people doing the work. To many executives, and even to their coworkers in sales or other parts of a company, programmers often seem to belong to an entirely different species. Communicating with them is frustratingly hard. They fail to respond to applications of the usual reward/punishment stimuli. They are geeks, and they are a problem."

I'm not a programmer, yet I found this book fascinating reading and learning about the dynamics of creating some of these monstrous programs. Vista, anyone?

Similar recommended titles: The Soul of a New Machine by Tracy Kidder.

OK, I admit it. I'm adding a quote that is very interesting but it also represents my playing around with my clippings file on the Kindle to see how easy it is to save and export quotes, etc. Really easy, as it turns out. This one relates to the difficulty of managing programmers (kind of like herding cats) and much of the reason stems from the attributes (almost an autistic or Asperger's personality -- in fact, there has been an explosion of diagnosed autism in Silicon Valley) of programmers.

"Forty-one percent of the IT professionals surveyed reported being introverted thinkers (combination of introversion and thinking preferences), nearly twice the percentage in the general population. Introverted thinkers often prefer a lone-gun approach to work, often avoiding teams, collaborative efforts, and the training that support such structures. This group is least likely to engage and connect interpersonally with others, and may avoid creating personal bridges of trust and openness with colleagues. . . A lot of people feel that communicating with the information technology professional is just slightly harder than communicating with the dead,” Abby Mackness, an analyst with Booz Allen Hamilton who conducted the Human Dynamics study, joked as she presented its results to a crowd of defense contractor employees and consultants."

(less)

11 likes · like · see review

Jun 20, 2008 Rustam rated it 3 of 5 stars · review of another edition

This book had some interesting anecodetes, but overall, it sounded like a software engineering after-school special. Rosenberg made the software development lifecycle sound like it's as mystical experience, akin to studying the Kabballah (it's not), and he missed the mark on defining certain programming concepts (eg "late-binding") in a way that made me suspect he was trying to overdress his comprehension of the subject.

The truth is, this book does not describe a typical software project. Chandl...more

4 likes · like · see review

Dec 05, 2007 Nick Black rated it 4 of 5 stars · review of another edition

Dreaming in Code was an awful lot of fun, a good uplifting "Chicken Soup for the 3l33t Soul" kinda thing. I bought copies for everyone in my office. On the other hand, the first two chapters (after a strong, catchy Introduction, sigh) are downright painful, any code company that allows loud, messy dogs into the bowels of their austere Rigorium is obviously destined to fail, and what's up with all these girls writing code? I don't know how they do it on the West Coast, but I quote Ed Post's moder...more

2 likes · like · see review

Oct 03, 2007 Topher rated it 4 of 5 stars · review of another edition Recommends it for: non-programmers

Shelves: non-fiction

I have a degree in computer science, and my thesis in remote sensing involves a lot of programming. Despite that, I wouldn't ever describe myself as a programmer. I can do a little programming, I can do a little admin work, but I am not a normal computer professional.

It was refreshing to see other people having the same issues I do. I have an idea...I spec out how long it ought to take......and it is consistently only 1/2 (at best!) the time I need.

Computers are either insanely complex or insane...more

1 like · like · see review

Feb 24, 2012 Craig Cecil rated it 3 of 5 stars · review of another edition

Shelves: computers

This book is paradoxically similar to the content it covers—and therein lies the problem. Dreaming in Code follows (for a three year period) the genesis and subsequent never-ending development of the open-source Chandler personal information manager (PIM) project. As the book relates the meandering development process, much like Lawrence trekking through Arabia, so too does the actual chapter by chapter account. Just as you are settling in as an invisible listener at design meetings, suddenly yo...more

1 like · like · see review

Oct 30, 2009 Sueij rated it 3 of 5 stars · review of another edition

Recommended to Sueij by: Scott

Y'know, there were things about this book that were really, really great. Mostly, it was that this is a fantastic overview of computers, software, and the culture of those who make them. Want to know why code should be free ("free like speech, not like beer")? Ever heard of a "wiki" and wondered what it was? Did you know that "nerd" is uncool but "geek" is hot? This book, using fantastically accessible metaphors and descriptions, will tell you.

What's not so hot, though? Two things. The first is...more

2 likes · like · see review

Oct 25, 2009 David rated it 5 of 5 stars · review of another edition Recommends it for: white-collar everyone, all of my co-workers, anyone who works with computers

Recommended to David by: easement

I dithered a long time on whether or not to read this book; probably mostly because it's hard to believe that it's actually not about coding.

It's not about coding.

Certainly there's a lot about coding in it, but it's about working with people, attempting to solve unsolvable problems, history of programmatic problem-solving... I know, it sounds like it's about coding. And, I have to say, it's a must-read for anyone who even remotely works with software -- be it creating or using. It's a story abou...more

2 likes · like · see review

Mar 30, 2009 Al Swanson rated it 5 of 5 stars · review of another edition

Shelves: non-fiction, tech

For any programmer, especially any programmer who has worked in a large team, this will ring true. For managers of programmers, even more so!

The story, still ongoing, of a programming team attempting to write an 'ultimate' piece of software. Not like some sci-fi book, tho. Not some software to control the world or be the next killer app - just scheduling, notes, tasks... something 'simple'.

As the book points out, even with no constraints from others, building software from scratch is a dauntin...more

like · see review

Feb 24, 2010 Christy Ford rated it 4 of 5 stars · review of another edition Recommends it for: People who work with (or live with) programmers or the like

Recommended to Christy by: OCLC Developers Book Club

Shelves: work-related

This book describes itself as a chronicle of a semi-failed software project.

That narrative truly only makes up half of the book. The other half is a deep look into how computer people, and computer businesses work. Its anecdotes range from simple observations such as the fact that programmers tend to like Monty Python, to a layman's explanation of the halting problem, to introspection about whether the foundations of computing are inadequate.

Many of these tidbits are familiar to those who are p...more

like · see review

Aug 12, 2009 Cindy rated it 3 of 5 stars · review of another edition

Shelves: non-fiction

I'll start with the positives in the book. I found the technical details very accessible: explained well with just enough detail. I've only done small amounts of coding and I was surprised and impressed that I didn't get lost in the AJAX discussion, eg. After reading the book, I felt like I had a little primer into the development of web-based applications. Also, it was very fascinating to see how a large, complicated piece of software comes together, since this is how the book is advertised.

Unf...more

like · see review

Jun 04, 2009 Amy rated it 5 of 5 stars · review of another edition

Shelves: non-fiction

"Making software is still, and truly, hard." This observation is stated repeatedly throughout Dreaming in Code. Fortunately "the kind of difficulty software presents serves as a welcome contrast to the perplexing, unyielding frustrations of what geeks call our 'wetware' lives. It is self-contained. It is rational. And it harbors no malice."

From my limited experience, I have to agree wholeheartedly. Software is hard -- it is an act of creating something out of nothing. How can you possibly plan s...more

like · see review

May 05, 2009 Brittany rated it 3 of 5 stars · review of another edition

Shelves: technical, history

This book was interesting because the author switched back and forth between the history/current state of software and an open source development project. The insider view into the project and the background development made for an interesting read.

I most enjoyed the chapter "Engineers and Artists" where the development of software is compared with the art of writing. A good writer (and software developer) will revise and have his or her work reviewed many times before considering it finished. W...more

1 like · like · see review

Mar 25, 2012 kat rated it 3 of 5 stars · review of another edition

Shelves: read-in-2012

An interesting read, half the story of a typical start-up trainwreck and half a philosophical meditation on why, exactly, "software is hard". Rosenberg takes the time to explain quite a lot about coding and programmer culture in layman's terms -- which is redundant for most programmers, while still being technical enough that I'm not sure, say, my parents would be able to get through it. I think the ideal audience is entrepreneurs and those who find themselves in the position of needing to manag...more

like · see review

Apr 11, 2009 Allisonperkel rated it 4 of 5 stars · review of another edition

Shelves: non-fiction, programming

Sometimes you read a book and you find yourself feeling an eerie sense of Deja Vu. Dreaming in Code is just such a book. The main premise surrounds the Chandler project and how its project lifecycle grows and changes over time.

What was truly fascinating was watching all the pitfalls the project went through. In almost every case I had the sense of having had that happen - from feature creep to lack of testing to a un-articulated design - I've been there. Its even more interesting to see the sam...more

like · see review

Oct 03, 2012 Travis Todd rated it 4 of 5 stars · review of another edition

I read this book because I wanted to learn more about what software actually IS and what's required to build a successful version of it and to generally increase my computer literacy, which is currently close to nil. Basically, it's a lot more complicated than I ever thought, and there are many theories about the best approach to building useable software within reasonable time constraints. There were sections where the Chandler team was described sitting in offices and scribbling on whiteboard...more

like · see review

Oct 11, 2012 Randall rated it 4 of 5 stars · review of another edition

The book chronicles Rosenberg's attempt to write about Open Source Software and its drift into an exploration of "software time", or the cycles and trials of software development, as experienced by a fly on the wall at the Open Source Applications Foundation during the development of their productivity software, Chandler. Rosenberg's style is friendly, making this a fairly quick read, and he does a good job of balancing exploration and summary to keep the narrative accessible, yet mildly technic...more

like · see review

Aug 24, 2009 Kelley rated it 5 of 5 stars · review of another edition Recommends it for: people who write code, their managers, and people who love but don't understand geeks

I'm currently reading Scott Rosenberg's _Dreaming in Code: Two Dozen Programmers, Three Years, 4732 Bugs, and One Quest for Transcendent Software_.

I'm about 1/2 way in; good book. It's worth a read if you're in the business, a storehouse of all the things you already know, but put together in a "big picture" way. It's also a decent introduction to the world of your favorite (or hated) geek because Rosenberg is especially adept at translating the world of computers and software into language that...more I'm currently reading Scott Rosenberg's _Dreaming in Code: Two Dozen Programmers, Three Years, 4732 Bugs, and One Quest for Transcendent Software_.

I'm about 1/2 way in; good book. It's worth a read if you're in the business, a storehouse of all the things you already know, but put together in a "big picture" way. It's also a decent introduction to the world of your favorite (or hated) geek because Rosenberg is especially adept at translating the world of computers and software into language that a non-insider can likely grasp. (Although, to be fair, I'm probably a poor judge of that.) Even so, Rosenberg stops and explains things like why a geek counts from 0.

He has an especially lucid discussion of something I tried to say very long ago, though Rosenberg does not put in my terms. I'd argued, back in 2004 IIRC, that postmodernist/poststrcuturalist thought was difficult to understand because it was trying to describe something very complicated itself. At the time, I likened it to the same reason why non-insiders don't understand why software is buggy, why you have a hard time making it do things the way you think they ought to be done. It's because the way software works, well, it has no center.

Which is why I likened it to po-mo - which is trying to describe a world that has no center.

Rosenberg grapples with this problem as well:

"Software is different; it has no core. It is onionlike, a thing of layers, each built painstakingly and precariously on the previous one, each counting on the one below not to move or change too much. Software builders like to talk about laying bricks; skeptics see a house of cards. Either way, there's a steady accumulation going on. New Layers pile on old.

Programmers call these accretions "layers of abstraction," because each time a new one is added, something complex and specific is being translated into something simpler and more general. The word 'abstraction' comes from the Latin for 'draw away'; here's one computer science definition of the term: "The process of combining multiple smaller operations in a single unit that can be referred to by name." Abstraction begins in the nursery. It is what children learn when they realize that if they want an apple, they don't have to find one to point to but can simply say the word that refers to it. They also learn that abstraction depends on a common language, on shared assumptions of what class of objects the word 'apple' refers to.

'This is what programmers do," wrote Eric Sink, a programmer who led the creation of the Web browser that became Microsoft's Internet Explorer. "We build piles of abstractions. We design our own abstractions and then pile them up on top of layers we got from somebody else."And every year the piles grow higher."

pp. 65-6

Badiou is in, waiting at the post office. I will probably finish Dreaming in Code tomorrow or Friday, maybe take a break and dive into Badiou this weekend or next week. I am not sure if we are going to engage in a more organized group reading of Badiou or not, but it certainly seems as if there are plenty of people trying to make (or re-make) their way through Badiou.
(less)

like · see review

Jan 31, 2009 Phil rated it 3 of 5 stars · review of another edition

An ok book, but I really dislike the title. A better title would be: "You're Fucked!"

The book tells (part of) the story of the Chandler Project (http://www.chandlerproject.org), a software project that wanted to create PIM software that would do such herculean tasks like "level all silos" and be all things to all people. Many very smart people worked on it for many years, wallowing in the tar pit before giving up on most of the goals just to produce something/anything usable. When the book ends,...more

like · see review

Aug 03, 2009 Darryl rated it 4 of 5 stars · review of another edition

This non-fiction book chronicles the slow and winding path toward the creation of an ambitious open-source information management application. If you've ever been involved in a less-than-successful IT project, the scenes in this book probably look all too familiar. I'm guessing more than a few readers have given in to the (misguided, IMO) tempation to spell out why this team struggled so much. If you really believe you've got the answers, I suspect you missed the point of the book.

Although this...more

like · see review

Jan 25, 2010 Xavier Shay rated it 2 of 5 stars · review of another edition

Easy read, but this book just frustrated me. I wanted to shout "YOU'RE DOING IT WRONG" throughout the whole thing. It's been half a decade since the events in the book and perhaps we've learned something since then, but I can't stand to watch a project run for 3 years with not much to show. Sure, Rosenberg learns the lessons, giving a diluted history of programming while he's at it, but for a professional programmer they're all old stories. By his own admission he has targeted the book at a wide...more

like · see review

Sep 13, 2012 Jessie Young rated it 4 of 5 stars · review of another edition

I was told that this book should be interested to just about anybody. I would edit that to say that it should be interesting to just about anybody who is interested in software more generally. I think I got a lot out of it because I am actually developing software, but the language is non-jargony and the stories are great for getting a sense of the history of programming.

Favorite bits:

"Time really does seem to behave differently around the act of making software. When things go well, you can lo...more

like · see review

Mar 07, 2012 Maciek rated it 4 of 5 stars · review of another edition

An outsider's look into software development as an endeavor (rather than just the elbow grease of writing code) chronicling the gestation and first steps of an ambitious open source project. Unfortunately, it's more a series of vignettes than a narrative. Although Rosenberg supports it well with background on relevant discussions and practices in the field, it still feels pretty scattered. Still, it's interesting as a non-technical (or at least low-technical) case study of a process that's becom...more

like · see review

Aug 24, 2011 Charles Baker rated it 4 of 5 stars · review of another edition

I really enjoyed this book. Not only did it address the particular problems of the Chandler project, it covered a lot of the history of software design, development and engineering. Rosenberg did his research. He referenced many of the books, people and methodologies with which I'm familiar such as Fred Brooks and his seminal book The Mythical Man Month, Ward Cunningham and et.al's eXtreme Programming and wikis, Watts Humphrey and his Personal Software Process, and more. If you aren't a software...more

like · see review

Feb 24, 2013 Irena rated it 1 of 5 stars · review of another edition

Shelves: my-audio-books

I don't recommend this book if you are a software engineer or manager, or any other kind of insider in the software development. You'll find little useful or interesting information here and lots of annoying demagogy. The only informative places were those that quoted books and articles on the matter written by professionals. However, the author did have one true epiphany: at the middle of the book he wrote that if the reader were a software engineer, he probably had thrown his book at the other...more

like · see review

Jun 22, 2011 Joe White rated it 4 of 5 stars · review of another edition

Shelves: on-shelf, techread

This was written from the standpoint of an inside observer to a technical programming based project, who himself was not a programmer.

I would recommend this to all my friends and relatives to whom I found it very hard to explain to them what programming is, and even worse how it integrates into larger projects. The book never gets overly technical, and does a fair job of guiding an under-informed reader into some of the historical issues with code development. In this case, the project followed...more This was written from the standpoint of an inside observer to a technical programming based project, who himself was not a programmer.

I would recommend this to all my friends and relatives to whom I found it very hard to explain to them what programming is, and even worse how it integrates into larger projects. The book never gets overly technical, and does a fair job of guiding an under-informed reader into some of the historical issues with code development. In this case, the project followed is Chandler, which still exists, although I don't know if it is in the same form as developed here in Python with a wxWidgets interface. This book ends at what was then the upcoming release of version 0.6.
It is one of the few books I have read that covers in a literary fashion anything remotely connected to an open source project - other than Linus's book.

The good stuff: Some of the main characters should be/are legends in the software industry, and the presentation here is a look at a summarized daily life type development cycle for those types of coders.

The bad side: I think that too much reverence was paid to historical 60's, 70's, and 80's influences. It was good to lay the foundation of development problems and give the reader something to gauge history by, but it seemed to me to drag the book down in looking for the eternal quest to develop a precise way to develop software from a coders viewpoint.
I think that more detailed information should have been presented regarding actual code, and actual bugs, since these topics are heavily referenced as a scaffold to support the development plot. Time slippage of the development milestones is explained and discussed from the standpoint of adding new team members and team size, but actual problems encountered were never discussed at the detail level from a code difficulty standpoint. There was also the referencing of "lines of code" as a measure of output and the author somewhat tried to explain how this is an ineffective measure, but I think that revealing the size of individual Python modules and how they interrelate might have given the novice reader a better picture of the scope of the complexity and a more true picture of what bugs are and how they are traced or evaluated in source code.
The book is pretty short, but this is definitely not a fiction-based page-turner with a twisting plot, so it took some time and effort to maintain a high interest level and drive to completion.
(less)

like · see review

Feb 13, 2010 gargamelscat rated it 2 of 5 stars · review of another edition

Shelves: 2010, business

About 2/3 of the way through this book the author detours for a couple of chapters through 40 years of software development methodology at a high level which will at least tangentially relevant to the story felt bolted on and lacked sufficient analysis and insight to hold my attention.

The book is a strange mix - not technical enough to interest developers and lacking the kind of narrative verve that made Kidder's 'Soul of a New Machine' such a killer book even for people not interested in the su...more

like · see review

Feb 08, 2010 Kelley rated it 5 of 5 stars · review of another edition Recommends it for: software developers, anyone who wants to understand the geek in their life

Shelves: web-development-and-web-design, it-busines-and-management

Everyone in IT has probably heard the chestnut, "You can have it good, cheap, and fast. Pick two." Scott Rosenberg tackles the assumptions behind that chestnut head on. What happens when you have a software project that has plenty of money, plenty time, and plenty of talent and experience? That project, Open Source Application Foundation's Chandler, turns out to suffer from all the problems that plague software development in spite of its wealth of resources. It's buggy. Deadlines are missed. Fe...more Everyone in IT has probably heard the chestnut, "You can have it good, cheap, and fast. Pick two." Scott Rosenberg tackles the assumptions behind that chestnut head on. What happens when you have a software project that has plenty of money, plenty time, and plenty of talent and experience? That project, Open Source Application Foundation's Chandler, turns out to suffer from all the problems that plague software development in spite of its wealth of resources. It's buggy. Deadlines are missed. Features get left behind. Decision-making is slow. The rise of the Web as an application platform upends the project turning Chandler into shelfware.

A lot of digital ink is spilled on the problem: why do IT projects fail so spectacularly? Itâ??s the subject of the Standish's Group Chaos report, distributed yearly since 1994. Rosenberg investigates the usual suspects fingered for IT project failure. Tackling one of the noisiest debates, Rosenberg argues that Chandler shows us just how wrong FOSS enthusiasts have been when, following Eric Raymond, they've touted FOSS because it produces less buggy software: "with enough eyeballs, all bugs are shallow." In spite of its open source status, in spite of the voluntarism, Chandler doesn't command nearly enough volunteer eyeballs to find the bugs. Most of them are found by employees instead.

Rosenberg also explodes other mythodologies (misspelling intentional) of software development. Exploring the utopian software future outlined by object oriented programming enthusiasts, Rosenberg uncovers some tough realities. The idea of building code in chunks to create interchangeable Lego parts is a great idea, but it never really works out in practice. Rosenberg isn't exactly sure why this is the case, but he explores some possible reasons. Partly, it's because OO just doesn't fit well with the temperaments of most engineers who have learned not to trust other people's. They prefer rolling their own.

He also thinks it's b/c engineers haven't really come to grips with the nature of software to begin with: it has no center. There is no core. It's endless layers of abstraction:

"Software is different; it has no core. It is onionlike, a thing of layers, each built painstakingly and precariously on the previous one, each counting on the one below not to move or change too much. Software builders like to talk about laying bricks; skeptics see a house of cards. Either way, there's a steady accumulation going on. New Layers pile on old."

Rosenberg also looks at the personalities of engineers themselves, asking: What is it with the tendency to want to start every project by first building the right tools with which to carry out the project. It's as if, in order to take the SAT exam, you first roll your own calculator. I've seen this countless times as engineers contemplate how to first build a better CMS instead of just getting down to business and coding the project at hand.

Frankly, I find it comforting to know that every single one of the problems I observe in web and software development are problems experienced by even the most well-funded project guided by big brains, great management, and deep experience. Rosenberg reminds me that another outfit with a whole lot going for it made the same mistakes I'm observing in organizations with far fewer resources and much more aggressive deadlines - organizations surely lacking in any FOSS philosophy toward software development.

For me, it's liberating to know that even if you fixed the time/talent/resources problem, things might not change. I can also see how Rosenberg's book might be depressing. It means that there is no magic bullet. Open source methodologies won't necessarily fix things. Tons of money, resources, talent, and experience may not address the problems. Profit motives just might not be the problem. We are stuck with this crazy world of IT development and the answers are probably located in something a lot more foundational: like how we think of software in the first place.

The answer, Rosenberg suggests, is in the very 'nature' of the reality we are working on. As such, tweaking software development methodologies, without questioning the ontology, is never going to be enough. We're going to have to look elsewhere for solutions. We're going to have learn to work in a world were there is no center. It's contingent foundations all the way down - like it or not. Embracing that means we have to think about software very differently. Consider one example often discussed among UNIX wizards: the metaphors we use to such as folders and files draws on a metaphor that once made sense when we had metal files and paper folders. As Rosenberg shows, though, the metaphor is limiting; it restricts our thinking.

Will rethinking the reality of software change things? I don't know. But, to me, that is the adventure and what makes life worth living.(less)

like · see review

Oct 30, 2008 Muhammad rated it 5 of 5 stars

Software is hard ! Begitu kata Donald Knuth sang maestro yang berpendapat bahwa "menulis" software adalah kegiatan seorang seniman. Buku ini menceritakan sulitnya membangun aplikasi PIM (personal instant messenger) yang didapuk untuk menjadi solusi bagi pengguna MS Exchange yang tidak ingin terikat lisensi komersilnya Microsoft. Rencana yang tadinya akan selesai dalam setahun ternyata molor sampai bertahun-tahun dan itupun jauh dari spec semula berupa grand design yang menjanjikan sebuah perubah...more

like · see review

Apr 15, 2013 Rod Hilton rated it 3 of 5 stars · review of another edition

Shelves: business, technology, programming, have-softcopy, have-hardcopy, audiobooks

Dreaming in Code is a book about software development. As a software developer, I cannot tell you how many times I completely related to the proceedings. All of the mistakes, all of the problems, all of the concerns, all of the date slipping, everything. It all felt so familiar, so "been there, man". To some extent, that's the problem with the book.

I've tried to read Dreaming in Code on 3 separate occasions. The idea sounded interesting, and the title alone piqued my interest, so I purchased the...more Dreaming in Code is a book about software development. As a software developer, I cannot tell you how many times I completely related to the proceedings. All of the mistakes, all of the problems, all of the concerns, all of the date slipping, everything. It all felt so familiar, so "been there, man". To some extent, that's the problem with the book.

I've tried to read Dreaming in Code on 3 separate occasions. The idea sounded interesting, and the title alone piqued my interest, so I purchased the hardcover book when it came out. I tried reading it, but simply was unable to get into it. A few years later, I acquired the ebook, so I could read it any time like on the bus or on my phone. I got a bit further, but still lost interest. Finally, I made it through the book by buying the audiobook version of it and listening while driving or working out. It somewhat perplexed me that I had such a hard time getting into the book, considering that I found "Masters of Doom", a very similar book about the struggles of a series of software projects (Wolfenstein, Doom, Quake, etc) to be one of the best books I read in the last year.

The difference between these two books lies in how they were written. Masters of Doom was written after the fact, by interviewing people associated with the projects and assembling an historical narrative from these accounts. Dreaming in Code was written by an embedded journalist, who was actually IN the offices where the software was being written, writing about it as it was being developed and eventually picking an arbitrary point in time to cut the book and release it. The difference is important, for one simple reason. Masters of Doom was allowed to be about some of the most groundbreaking games ever created, with the full knowledge of history at the disposal of the author. Dreaming in Code is about the development of a personal information manager called Chandler, which I never heard of before reading the book.

Masters of Doom was fun not only because I could relate to so many of the trials and tribulations of software development that it discussed, but also because I was familiar with the software itself and interested in its history. Chandler is just some Outlook-esque type program, some boring office software meant to emulate Lotus Agenda (which I had also never used). As such, there is nothing interesting about the software itself or its history, so all that's left in Dreaming in Code is the process of development software, and the issues that arise.

As a longtime software developer, these issues were so familiar to me that I found it almost boring. I was so familiar with these woes that it didn't feel like I was really learning anything or gaining new insight. There were occasional passages that I found enlightening, and I wound up definitely taking a handful of "look this up later" type notes, but they were few and far between in light of the book's considerable length. The book almost would be better suited for someone who was NOT familiar with the process of software development, but as countless conversations about my workday with my wife have indicated, nonprogrammers tend not to give a flying rat's fuck about the process of software development.

I would recommend this book, but not to developers, nor to people with no connection to development. I'd recommend it to anyone who works at a company that develops software, but who is not actually on the development team. Salespeople, customer support, maybe even high-level managers, those sorts of folks. I think the book sheds a lot of light on what goes wrong with development projects, and people whose lives are affected by development projects may well find it very interesting and clarifying. It might also be good for those who are interested in becoming software developers, or college students majoring in Software Engineering or Computer Science (but be warned, the Chandler project is particularly dysfunctional, and I recognized its problems mostly from the worst jobs I've ever had, not the best). Those who live this life will find it boring, as will anyone whose interactions with software are limited to its usage.(less)

like · see review

Aug 14, 2009 Gingeraltoids rated it 5 of 5 stars

I was given this book as a gift from the Computing Sciences Dept. at Villanova for the Best Independent Study 2006 award. It looks like a great book and I am looking forward to reading it.

Update after reading it
Great book! If you want to understand what us software engineers do all day, or how the software you use everyday gets built, this is the book. No technical expertise or programming experience is required to enjoy this book -- there's only one tiny little example of code in the whole book...more

1 like · like · see review

« previous 1 2 3 4 5 6 7 8 9 … 61 62 next »

new topic
Discuss This Book

There are no discussion topics on this book yet. Be the first to start one »

Recommend it | Stats | Recent status updates

combine
Other Editions (3)

Goodreads is hiring!

If you like books and love to build cool products, we may be looking for you.
Learn more »

Genres

Computer Science > Programming

49 users

Non Fiction

37 users

Science > Technology

19 users

Computer Science > Computers

15 users

Business

12 users

Computer Science > Software

12 users

Science > Computer Science

7 users

History

6 users

Pop Culture > Geek

6 users

Computer Science > Technical

2 users

See top shelves...

Readers also enjoyed similar books

About Scott Rosenberg

Writer, editor and website builder SCOTT ROSENBERG is a cofounder of Salon.com and author of Say Everything: How Blogging Began, What It's Becoming and Why It Matters and Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest For Transcendent Software.

Librarian Note: There is more than one author in the GoodReads database with this name. See this thread for more informatio...more

More about Scott Rosenberg...

Books by Scott Rosenberg

Say Everything: How Blogging Began, What It's Becoming, and Why It Matters

Puroguramā No Jirenma: Yume To Genjitsu No Hazama

More…

Share This Book

Facebook Twitter Your website

Trivia About Dreaming in Code:...

No trivia or quizzes yet. Add some now »

Quotes from Dreaming in Code: Two ...

“The revolution has to be customised” — 1 person liked it

More quotes…

title link	preview: Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software
avg rating	preview: Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Sof Goodreads rating: 3.59 (877 ratings)
small image	preview: click here [close]
med image	preview: click here [close]
BBCode	[url=https://www.goodreads.com/book/show/1228489.Dreaming_in_Code?utm_medium=api&utm_source=blog_book][img]https://d202m5krfqbpi5.cloudfront.net/books/1320431139l/1228489.jpg[/img][/url] [url=https://www.goodreads.com/book/show/1228489.Dreaming_in_Code?utm_medium=api&utm_source=blog_book]Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software by Scott Rosenberg[/url]

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

Friend Reviews

Community Reviews

Goodreads is hiring!

Share This Book

Share This Book on Your Website