Reviews from Amazon

Reviews elsewhere on the web:

ZDNet.co.uk

Scott Rosenberg

Dreaming in Code

Software projects are notorious for their problems - time and budget overruns, bugs and feature creep. In Dreaming in Code Scott Rosenberg describes the early days of development of Chandler by the OSAF. This was developed as an open source program, but with substantial funding, so one might think it could avoid the usual problems of software development. But it seems nothing is immune, and problems soon arose. In particular, there was little financial pressure to get something out of the door and version 1.0 always seemed to be a couple of years away.

In 2002, when Rosenberg decided to sit in on the development of Chandler, it seemed that it would take about a year to have a viable product. Three years later it was something of a problem to finish a book about a project which was taking so much time. But Rosenberg is a skilled writer, and rather than just describe the day to day discussions of the project he includes plenty of material about the history of the problems of software development, the proposed solutions, and why these solutions didn't work. The book is aimed at a non-specialist readership, and will be of interest to anyone who wants to find out why writing software is such a problem.

Amazon.com info

Hardcover 416 pages
ISBN: 1400082463
Salesrank: 305870
Weight:1.5 lbs

Published: 2007 Crown

Marketplace:New from $5.94:Used from $0.35

Buy from Amazon.com

Amazon.co.uk info

Hardcover 416 pages
ISBN: 1400082463
Salesrank: 336320
Weight:1.5 lbs

Published: 2007 Crown Publishers

Marketplace:New from £7.13:Used from £1.70

Buy from Amazon.co.uk

Amazon.ca info

Hardcover 416 pages
ISBN: 1400082463
Salesrank: 171251
Weight:1.5 lbs

Published: 2007 Crown

Amazon price CDN$ 21.42

Marketplace:New from CDN$ 11.52:Used from CDN$ 3.38

Buy from Amazon.ca

Product Description
Their story takes us through a maze of dead ends and exhilarating breakthroughs as they and their colleagues wrestle not only with the abstraction of code but with the unpredictability of human behavior, especially their own. Along the way, we encounter black holes, turtles, snakes, dragons, axe-sharpening, and yak-shaving—and take a guided tour through the theories and methods, both brilliant and misguided, that litter the history of software development, from the famous “mythical man-month” to Extreme Programming. Not just for technophiles but for anyone captivated by the drama of invention, Dreaming in Code offers a window into both the information age and the workings of the human mind.

Product Description

Their story takes us through a maze of dead ends and exhilarating breakthroughs as they and their colleagues wrestle not only with the abstraction of code but with the unpredictability of human behavior,
especially their own. Along the way, we encounter black holes, turtles, snakes, dragons, axe-sharpening, and yak-shaving—and take a guided tour through the theories and methods, both brilliant and misguided, that litter the history of software development, from the famous “mythical man-month” to Extreme Programming. Not just for technophiles but for anyone captivated by the drama of invention, Dreaming in Code offers a window into both the information age and the workings of the human mind.

Absolutely a great read! *****
I had to read this book prior to my first class at Carnegie Mellon University (MS program). Unlike most reading material provided by schools (which is dry and boring), this was a well-written, interesting book which described every software developers encounter with "Software time". This book even goes back to the early days of computing along with the great minds which revolutionized the way software behaves to provide insight and background during the course of one particular software team's struggle for transcendalized code. I have had the instances in this book happen to me (pitfalls, perils, mistakes, etc) and I thought it was so applicable to my career path going forward. Oddly enough, I thought "Dreaming In Code" was a clever title considering that I myself had coded school projects in my sleep and the book does provide an illustration near the end on what the statement actually means.

Absolutely a great read! *****

I had to read this book prior to my first class at Carnegie Mellon University (MS program). Unlike most reading material provided by schools (which is dry and boring), this was a well-written, interesting book which described every software developers encounter with "Software time". This book even goes back to the early days of computing along with the great minds which revolutionized the way software behaves to provide insight and background during the course of one particular software team's struggle for transcendalized code.

I have had the instances in this book happen to me (pitfalls, perils, mistakes, etc) and I thought it was so applicable to my career path going forward. Oddly enough, I thought "Dreaming In Code" was a clever title considering that I myself had coded school projects in my sleep and the book does provide an illustration near the end on what the statement actually means.

Good for non-programmers ***
This is good book for non-programmers that explains on why software is hard to do and how the projects are delayed. However, there is a question of will the non-programmers read throught the 350 pages just to know that. My guess is not. For programmers, the books is old news. Been there, done that. Do you need a book to remind you of the last project that went late? Not all is bad, there are nice chapters for everyone, where the author talks about future of software development. However, those chapters are only a side-track that are made to explain the problems and challanges of software development.

Good for non-programmers ***

This is good book for non-programmers that explains on why software is hard to do and how the projects are delayed. However, there is a question of will the non-programmers read throught the 350 pages just to know that. My guess is not.

For programmers, the books is old news. Been there, done that. Do you need a book to remind you of the last project that went late?

Not all is bad, there are nice chapters for everyone, where the author talks about future of software development. However, those chapters are only a side-track that are made to explain the problems and challanges of software development.

Software development blues ****
"Dreaming in Code" follows the software development team responsible for Chandler, an open-source personal information manager (calendar+contacts+etc) over a few years. The author sought to find out why software projects more often than not come in horridly behind schedule and over budget, and despite all the advances and tools available to programmers, the answer seems to be the same in every case: overzealous and unrealistic goals from the management/customer...even when you have legends in the field working on the team. The prose is very relaxed and easy-going, almost to conversational, so this is a surprisingly quick read. The book is about 2/3 following the day-to-day of the development team, 1/3 philosophizing about what programmers do and should do. The team started to grate on me after a while...maybe it was the whole "change the world" holier-than-thou approach they took to their project. It's just a calendar, and if you do a little research, it is utterly underwhelming. The history and philosophy of programming as the author sees it was very interesting, since I'm something of a code monkey myself. A reader from the general public might not appreciate that part so much, but this book will give most people a better sense of why software is buggy and takes so long to develop.

Software development blues ****

"Dreaming in Code" follows the software development team responsible for Chandler, an open-source personal information manager (calendar+contacts+etc) over a few years. The author sought to find out why software projects more often than not come in horridly behind schedule and over budget, and despite all the advances and tools available to programmers, the answer seems to be the same in every case: overzealous and unrealistic goals from the management/customer...even when you have legends in the field working on the team. The prose is very relaxed and easy-going, almost to conversational, so this is a surprisingly quick read.

The book is about 2/3 following the day-to-day of the development team, 1/3 philosophizing about what programmers do and should do. The team started to grate on me after a while...maybe it was the whole "change the world" holier-than-thou approach they took to their project. It's just a calendar, and if you do a little research, it is utterly underwhelming. The history and philosophy of programming as the author sees it was very interesting, since I'm something of a code monkey myself. A reader from the general public might not appreciate that part so much, but this book will give most people a better sense of why software is buggy and takes so long to develop.

A Tale Of Nightmare *****
Scott Rosenberg became an embedded journalist in the trenches of software development back in 2003 to write the book "Dreaming In Code". The project is about writing a Personal Information Management or PIM software in the wee years of the Twentyfirst Century. What started out with excitement of "changing the world"--probably with free bagels--seems to have proceeded with anxiety ridden horror stories. Dozens of industry recognized experts having been involved with the Chandler project, named after Mitch Kapor's whim as the project itself had been, left the project because it had gone past the threshold of fun and into the realm of tedious work. Most of these experts, such as Andy Hertzfeld (!), were presumably already millionaires, so the work had to be fun because they were not in it for the money, but for the love of creating something other people will love to use it. There is plenty of satisfaction by making a positive contribution to society. A project that had been slated for one year dragged on for years and didn't become "dogfoodable" until the second half of the decade, and I'm not sure if it is dogfoodable even now (I downloaded it and puked.) Much of the problems seem to revolve around three groups of people: visionaries, managers, and developers. The role of the visionaries is to think outside the box, whereas the managers' role is to identify what that box is and put in constraints that make up the walls of the box. Software developers can be in both categories, they are by definition creative. Breaking down a constraint, or shattering the walls of such a box--a characteristic of creativity--if allowed by a manager, can dissolve the box, and then you have nothing. Rosenberg's research for this book is very impressive. He writes of the milestone thoughts of true giants of the software industry. From Alan Turing to Edsger Dijkstra to Donald Knuth to Frederick Brooks, Rosenberg quotes them in an attempt to explain what went wrong in the Chandler project. Rosenberg never mentions one notable person, the first programmer in the history of computers. That would be Ada Lovelace. In the early 1880s she wrote a note, Note G, related to Charles Babbage's The Analytical Engine, or the version 2 of the Difference Engine, neither of which had become dogfoodable during Babbage's time. In this note, she writes a computer program with variables, loops, and conditions, to generate a set of the Bernoulli Numbers. The code has been deemed by experts who studied it as...bug free. End of book notes are full of valuable links. Most of the links work. It's interesting that the links to the blogs of Michael Toy, one of the managers of the Chandler project, are missing in the OSAF website.

A Tale Of Nightmare *****

Scott Rosenberg became an embedded journalist in the trenches of software development back in 2003 to write the book "Dreaming In Code". The project is about writing a Personal Information Management or PIM software in the wee years of the Twentyfirst Century. What started out with excitement of "changing the world"--probably with free bagels--seems to have proceeded with anxiety ridden horror stories. Dozens of industry recognized experts having been involved with the Chandler project, named after Mitch Kapor's whim as the project itself had been, left the project because it had gone past the threshold of fun and into the realm of tedious work. Most of these experts, such as Andy Hertzfeld (!), were presumably already millionaires, so the work had to be fun because they were not in it for the money, but for the love of creating something other people will love to use it. There is plenty of satisfaction by making a positive contribution to society. A project that had been slated for one year dragged on for years and didn't become "dogfoodable" until the second half of the decade, and I'm not sure if it is dogfoodable even now (I downloaded it and puked.) Much of the problems seem to revolve around three groups of people: visionaries, managers, and developers. The role of the visionaries is to think outside the box, whereas the managers' role is to identify what that box is and put in constraints that make up the walls of the box. Software developers can be in both categories, they are by definition creative. Breaking down a constraint, or shattering the walls of such a box--a characteristic of creativity--if allowed by a manager, can dissolve the box, and then you have nothing.

Rosenberg's research for this book is very impressive. He writes of the milestone thoughts of true giants of the software industry. From Alan Turing to Edsger Dijkstra to Donald Knuth to Frederick Brooks, Rosenberg quotes them in an attempt to explain what went wrong in the Chandler project. Rosenberg never mentions one notable person, the first programmer in the history of computers. That would be Ada Lovelace. In the early 1880s she wrote a note, Note G, related to Charles Babbage's The Analytical Engine, or the version 2 of the Difference Engine, neither of which had become dogfoodable during Babbage's time. In this note, she writes a computer program with variables, loops, and conditions, to generate a set of the Bernoulli Numbers. The code has been deemed by experts who studied it as...bug free.

End of book notes are full of valuable links. Most of the links work. It's interesting that the links to the blogs of Michael Toy, one of the managers of the Chandler project, are missing in the OSAF website.

Vivid record of a software project, better if the author stays quiet ****
The book follows the birth and development of an ambitious project named Chandler (Now you can find a Working Version 1.0!). The story is typical for virtually any software project. Started with ambitious vision and goals, facing a lot of problems and forced to scale back, a LOT of delays, and at the end (so far) kind of losing its momentum. As a person earning money by writing codes (no comparison whatever to "star" programmers who show up in the book...), the vivid description of people around the project is enjoyable, and made me think of my own projects and how I work more than occasionally. I enjoyed reading the book a lot. What is a bit annoying is when the author starts inserting his opinion, or try to generalize what is going on often by citing some other people's words. The analysis is usually shallow (I can easily see that he is writing for WIRED), sometimes imprecise or off the mark (which is typical of non specialist somebody who does not have an hands on experience). But probably it is a necessary evil since, if the author writes in a way that I am more comfortable with, the book becomes boring and thus cannot attract great audience (outside the professionals in the field). I think the book is even more entertaining if the author has a bit more self-restraint and stays behind the stage. Not many people is expecting the author's opinion. I wish the author spends more pages describing the details of the discussion taking place around the project or what the author heard from the project members. But all in all, I enjoyed a lot and recommend the book.

Vivid record of a software project, better if the author stays quiet ****

The book follows the birth and development of an ambitious project named Chandler (Now you can find a Working Version 1.0!). The story is typical for virtually any software project. Started with ambitious vision and goals, facing a lot of problems and forced to scale back, a LOT of delays, and at the end (so far) kind of losing its momentum.

As a person earning money by writing codes (no comparison whatever to "star" programmers who show up in the book...), the vivid description of people around the project is enjoyable, and made me think of my own projects and how I work more than occasionally. I enjoyed reading the book a lot.

What is a bit annoying is when the author starts inserting his opinion, or try to generalize what is going on often by citing some other people's words. The analysis is usually shallow (I can easily see that he is writing for WIRED), sometimes imprecise or off the mark (which is typical of non specialist somebody who does not have an hands on experience). But probably it is a necessary evil since, if the author writes in a way that I am more comfortable with, the book becomes boring and thus cannot attract great audience (outside the professionals in the field).

I think the book is even more entertaining if the author has a bit more self-restraint and stays behind the stage. Not many people is expecting the author's opinion. I wish the author spends more pages describing the details of the discussion taking place around the project or what the author heard from the project members.

But all in all, I enjoyed a lot and recommend the book.

The case against open source - unfortunately ***
While trying to write a review on Amazon I struggled with whether to give it 0, 3 or 5 stars, let me explain First the book is about the development of Chanlder, a next generation PIM sponsored by Mitch Kapor, ex Lotus Chief and with some of the big names in software development and open source, including Andy Hetzfeld whold wrote most of the original Max UI code. What strikes you while reading this is what a complete disaster the project was, they seem to spend weeks if not months "thinking" about the design, navel gazing like never before. The book seems to suggest the designers never once tried to use actual customers or possible customers to understand the problem domain but instead came up with wierd and wonderful designs from the UI down to the lowest level code, most of which were near impossible to implement The author then goes on to suggest, many times in the book, that software is hard and thats a fact. My god, its hard the way these people tried to develop it. On the back of the book I downloaded Chandler, and what a waste of several man years, and several million $$'s its basically a very bad PIM that is barely intuitive, slow and to be honest a bit c**p. So back to the review, if you want to read about the trials and tribulations of a complete mess of a software project, buy this book, 5 stars If you want to read about how not to design and develop software in the current internet age, buy this book, 5 stars If you want to read about how some of the apparent great minds in open source, are not really that great at working as a team in a real company, buy this book, 3 stars If you want the author to describe every computer programming term in the most basic definition, buy this book, 2 stars If you want to learn how to write great software, don't buy this book, 1 star Poor people, you really did get it wrong

The case against open source - unfortunately ***

While trying to write a review on Amazon I struggled with whether to give it 0, 3 or 5 stars, let me explain

First the book is about the development of Chanlder, a next generation PIM sponsored by Mitch Kapor, ex Lotus Chief and with some of the big names in software development and open source, including Andy Hetzfeld whold wrote most of the original Max UI code.

What strikes you while reading this is what a complete disaster the project was, they seem to spend weeks if not months "thinking" about the design, navel gazing like never before. The book seems to suggest the designers never once tried to use actual customers or possible customers to understand the problem domain but instead came up with wierd and wonderful designs from the UI down to the lowest level code, most of which were near impossible to implement

The author then goes on to suggest, many times in the book, that software is hard and thats a fact. My god, its hard the way these people tried to develop it.

On the back of the book I downloaded Chandler, and what a waste of several man years, and several million $$'s its basically a very bad PIM that is barely intuitive, slow and to be honest a bit c**p.

So back to the review, if you want to read about the trials and tribulations of a complete mess of a software project, buy this book, 5 stars
If you want to read about how not to design and develop software in the current internet age, buy this book, 5 stars
If you want to read about how some of the apparent great minds in open source, are not really that great at working as a team in a real company, buy this book, 3 stars
If you want the author to describe every computer programming term in the most basic definition, buy this book, 2 stars

If you want to learn how to write great software, don't buy this book, 1 star

Poor people, you really did get it wrong

The 'Spinal Tap' of software. ***
The story this book tells would be funny if it weren't so tragic. It's the sad tale of a piece of software - started in 2002 - that STILL is very, very far from finished. I purchased the book because I was (briefly!!!) interested in the software - a Personal Information Manager called Chandler (you can go to chandler.org and download it yourself, if you have some time to waste.) I read the book with a growing sense of disbelief - HOW many programmers? And some of them FAMOUS??? HOW much money?? HOW long??? And the software is STILL (sorry) a non-functioning piece of junk?? More than anything else, I was reminded of the movie 'Spinal Tap'... People who (to judge by this particular project) appear incompetent, talking like they are the source of all knowledge on the subject. If anything this book is a manual on how NOT to undertake a software project. Personally, I suspect that one single programmer, working in his spare time, could have produced a better program than Chandler, and reading this book only reinforced that belief. The failure of Chandler, of course, is not the author's fault. It's very clear that he's on the side of the programmers and their managers, and as the book closes you can sense his own sadness (tinged with disbelief) that he has to finish with no ending to his story. However, I've deducted a few stars because he sometimes wanders so far from the central story, sometimes for several chapters. We're given long essays on why software is 'hard', before returning to the Chandler story - and then the book almost disproves its own argument by ending with an example of how a single motivated programmer can make it look easy! A cautionary tale on why software should not be written by committee.

The 'Spinal Tap' of software. ***

The story this book tells would be funny if it weren't so tragic. It's the sad tale of a piece of software - started in 2002 - that STILL is very, very far from finished.

I purchased the book because I was (briefly!!!) interested in the software - a Personal Information Manager called Chandler (you can go to chandler.org and download it yourself, if you have some time to waste.)

I read the book with a growing sense of disbelief - HOW many programmers? And some of them FAMOUS??? HOW much money?? HOW long??? And the software is STILL (sorry) a non-functioning piece of junk??

More than anything else, I was reminded of the movie 'Spinal Tap'... People who (to judge by this particular project) appear incompetent, talking like they are the source of all knowledge on the subject.

If anything this book is a manual on how NOT to undertake a software project. Personally, I suspect that one single programmer, working in his spare time, could have produced a better program than Chandler, and reading this book only reinforced that belief.

The failure of Chandler, of course, is not the author's fault. It's very clear that he's on the side of the programmers and their managers, and as the book closes you can sense his own sadness (tinged with disbelief) that he has to finish with no ending to his story.

However, I've deducted a few stars because he sometimes wanders so far from the central story, sometimes for several chapters. We're given long essays on why software is 'hard', before returning to the Chandler story - and then the book almost disproves its own argument by ending with an example of how a single motivated programmer can make it look easy!

A cautionary tale on why software should not be written by committee.

Tell me something I don't already know ***
This is an extremely well-written book which is entertaining and easy to read. It's almost defining a new genre; rather than saying anything new to software practitioners, it reads like a popular science book. In a sense, this is like an episode of Horizon telling you why software is hard. And fundamentally, this is what the book says; it says, despite the best intentions of all involved, software is hard. It says this at the start, it says it at the end, and it says it in the middle. If you're in the industry, you won't find any new revelations here; if you haven't done so already, go and read "The Mythical Man-Month" for the lowdown on exactly why it's so hard. The book is written without finger-pointing, and that is its second greatest weakness. Scott Rosenberg decries how the software industry falls short of holding inquests into its failures, but then stops short of doing so himself. He hints that changing requirements are a Bad Thing, but doesn't challenge Chandler's design or technology choices, despite the fact that these are clearly contributing factors to the immense slippage. Overall, entertaining, light and fluffy - just don't expect it to tell you anything you don't already know.

Tell me something I don't already know ***

This is an extremely well-written book which is entertaining and easy to read. It's almost defining a new genre; rather than saying anything new to software practitioners, it reads like a popular science book. In a sense, this is like an episode of Horizon telling you why software is hard.

And fundamentally, this is what the book says; it says, despite the best intentions of all involved, software is hard. It says this at the start, it says it at the end, and it says it in the middle. If you're in the industry, you won't find any new revelations here; if you haven't done so already, go and read "The Mythical Man-Month" for the lowdown on exactly why it's so hard.

The book is written without finger-pointing, and that is its second greatest weakness. Scott Rosenberg decries how the software industry falls short of holding inquests into its failures, but then stops short of doing so himself. He hints that changing requirements are a Bad Thing, but doesn't challenge Chandler's design or technology choices, despite the fact that these are clearly contributing factors to the immense slippage.

Overall, entertaining, light and fluffy - just don't expect it to tell you anything you don't already know.

Excellent *****
Books on software and project management are by and large a dry bunch. This book most definitely isn't in that category. It is entertaining and engaging from start to finish. And written in an intelligent style that could to be admired for its own sake, but also well researched and illustrated with very well chosen quotes and examples. I was very impressed. It covers the development of Chandler from the initial concept through the design and prototype stages and towards the first working releases. It details the dead-ends and false starts that characterise many large projects and tries to explain how they happened. Along the way Scott explains a lot of the details of software design and development and its history in a clear and non-technical style. Definitely holding the "intelligent laymen" in mind he has written some very concise and readable descriptions of some fairly complex topics. Along the way he introduces some thought provoking points and even managed to clarify a few concepts that I thought I already understood (and I've 20 years of experience in programming!)

Excellent *****

Books on software and project management are by and large a dry bunch. This book most definitely isn't in that category. It is entertaining and engaging from start to finish. And written in an intelligent style that could to be admired for its own sake, but also well researched and illustrated with very well chosen quotes and examples. I was very impressed.
It covers the development of Chandler from the initial concept through the design and prototype stages and towards the first working releases. It details the dead-ends and false starts that characterise many large projects and tries to explain how they happened.
Along the way Scott explains a lot of the details of software design and development and its history in a clear and non-technical style. Definitely holding the "intelligent laymen" in mind he has written some very concise and readable descriptions of some fairly complex topics. Along the way he introduces some thought provoking points and even managed to clarify a few concepts that I thought I already understood (and I've 20 years of experience in programming!)

A fascinating insight into open source software development *****
I was very impressed by this book; it offers a fascinating insight into the trials and tribulations of developing a complex open source system. The author (who was not personally involved in the development) tracks the development of the system from conception to three years into the product development cycle. Open source projects are typically open-ended, and as such, the author is unable to track the development to a "final" release. However, he still offers a fascinating insight into the development challenges faced along the way. All in all, a pleasurable read.

A fascinating insight into open source software development *****

I was very impressed by this book; it offers a fascinating insight into the trials and tribulations of developing a complex open source system.

The author (who was not personally involved in the development) tracks the development of the system from conception to three years into the product development cycle.

Open source projects are typically open-ended, and as such, the author is unable to track the development to a "final" release. However, he still offers a fascinating insight into the development challenges faced along the way.

All in all, a pleasurable read.

Good book but with a misleading title... ***
I would re-title the book "Random Walk in Modern Software and Computing". It covers a lot of interesting stories and milestones about modern software. Anyone who has been exposed to the industry should have heard and known about them, although it would be difficult to find all of them to be mentioned in one place. If the book was titled that way, It would be an easy 4 - 4.5 out of 5. The coverage about what has mentioned in the title is minimal. If you are interested about the project like I do, you would be disappointed.

Good book but with a misleading title... ***

I would re-title the book "Random Walk in Modern Software and Computing". It covers a lot of interesting stories and milestones about modern software. Anyone who has been exposed to the industry should have heard and known about them, although it would be difficult to find all of them to be mentioned in one place. If the book was titled that way, It would be an easy 4 - 4.5 out of 5.

The coverage about what has mentioned in the title is minimal. If you are interested about the project like I do, you would be disappointed.