Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software by Rosenberg, Scott (2008) Paperback Unknown Binding
|New from||Used from|
Customers who viewed this item also viewed
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.
There was a problem filtering reviews right now. Please try again later.
A bit scrappy and could have done with a tougher editor.
As its a few years old events have over taken the project. The author speculates something Great! might still come from the project. Sadly history wasn't kind.
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.
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.
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.
Top international reviews
Chandler keeps on missing deadlines through the book. Halfway through it started getting on my nerves. There were times when I felt like stopping and writing to Kapor right away. One could argue that Chandler wouldn't have been a vapourware if they had chosen the web over python but that's exactly the kind of information that development team didn't have access to when they made the decision and thus led them astray. In a way, this changing topology is what makes making solid structures in software industry a challenging problem. OSAF is incredibly ambitious and stoic about their aspirations to take forward the ideas of Ted Nelson and Doug Engelbart.
Overall, I found it a great introduction to this industry as an outsider. Although the book doesn't expect the reader to be a programmer, it'll definitely help. Dreaming in Code encourages discussion which is why this will give you a lot of fodder to put on the coffee table with any software engineers you may know.
Se lavorate nell'ambiente troverete qualche aneddoto interessante e rivedrete molte cose che avete sicuramente vissuto di persona.
A differenza di quello che forse ci si potrebbe aspettare, le vicende umane, sopratutto la storia del ceo dell'azienda seguita dal libro, è di gran lunga la parte più interessante del libro.
Carino e scorrevole, la sua semplicità di lettura lo rende forse anche più utile come audiobook da ascoltare nel tragitto verso il lavoro.
For me, the book about the software project was the most interesting. The project is called Chandler done by a company called Open Source Applications Foundation (OSAF) by Mitch Kapor (the founder of Lotus). It's vision is to develop the next generation personal information manager (PIM), which is basically a calendar, email and note-maker integrated in one product. Chandler had a large investment and attracted some high-profile developers. Scott Rosenberg followed the Chandler project over a couple of years and the book describes his observations or narrative of the project.
The Chandler project is fascinating as they aim to do things different... and end up making all the mistakes of traditional software projects. They want to get something out quickly and facilitate an open source community to build up the product. They end-up over-designing, late delivering and over-complicating the whole project. It is really painful to follow the project (at least for me) as I could see them make the mistakes and would want to say "nooo!" but they did it anyways. Eventually the book ends without knowing the end of Chandler, but if you search online you'll discover that it unfortunately never delivered its vision.
The second book is the authors search for delivering better software. He basically picks a theme and describes that and explains some of the history. For example, at some point it explains what open source is and how open source was created. Similarly, it explains lots of aspects of software development. Most of these ought to be nothing new for nearly any software developer... and it suggests the book is actually targeted to people who aren't directly involved in software development but are curious about how it would work. The explorations were interesting but purposefully shallow, which made them a bit boring for me. Usually I ended up reading through them and wanting to go back to the Chandler project story to know what would happen there.
All in all, the book was well written. I enjoyed the Chandler parts a lot (4 stars) and felt the explorations were just ok (3 stars). I decided to average it out to 3 stars, especially for software developers who probably know all the explorations already. 4 stars for people who are interested in discovering more about software development. A pretty ok book.
There are two distinct matters to be discussed here: 1) the principle story of the book, and 2) how the subject matter is delivered.
The principle story of the book is Chandler, a Personal Information Manager(PIM)/Groupware-type software that was conceived and developed as an open-source project. The project was abandoned after several years' effort without having achieved its defining goals, and Dreaming is a narrative of the first few years.
The blame for the failure must be place squarely at feet of the project's founder and chief evangelist, Mitch Kapor. Mr. Kapor was the heroic developer of Lotus 1-2-3. For the growing number of you who have no idea what that was, it was the one app that made a PC worth having in the late 80s. It was the killer app for a long time.
Chandler was meant to be Kapor's extension of a PIM product that had once shown some promise at Lotus. He had the lofty idea of making this system capable of tying together all of the elements of PIM practice (calendar, task list, email, notes) into a seamless, ephemeral whole, without storage dictated by data type, and by the way, open source. Get it? Well, nobody else did either.
This project failed because its goal could not and cannot be articulated in a short sentence. It was consistently defined by its desired attributes, without the faintest idea of how it could be achieved. In fact, when examined more closely the defining attributes seemed to be in direct contradiction to each other.
If you will forgive me, the situation reminded me a lot of the health care bill of 2010. It was just forever before there ever was a bill. For at least two years, it existed as list of lofty attributes. For the few brief moments between the time it actually became a bill and the time it was passed into law, the Speaker of the House famously noted that we have to pass it to see what's in it. But when it was finally dissected, it contained a number of conflicting requirements that could not live together successfully.
And so it was with Chandler. I marvel at the fact that in the august collection of software professionals, no one at any point pitched a fit that the project had no clearly articulated mission, that they had not a clear image of what they were building, and how such building would occur. I presume it is because that in this particular open-source project, the developers were getting paid.
The open source idea was intended to harness the executional capacity of the masses, but again, the project was too ethereal for the masses to work on. There was no unifying mantra, such as "Write a free Unix!" or "Replace IIS!", for the masses to recite in unison. A candidate cry might have been "Replace Outlook!", but Chandler was meant to be so much *more* than Outlook. Unfortunately, "Transcend Outlook!" just never caught on. So Kapor paid a number of available systems development heavy hitters to develop the open-source project. Most of them moved along to other pastures once they saw that the emperor was in fact naked.
And all of that is pity, but again, the greater pity is that the disaster could not have been averted by a well-placed person pulling the emergency brake. In my experience in software development, you have a problem on your hands if your programmers start out by designing the splash screen. Similarly, that the software was named after the dog, the dog after the author, and the releases after the setting of the author's stories just makes me want to puke. Perhaps we could get the cart and the horse in the right order.
A number of reviewers of this book have noted that the book is just as unfocused and wandering as the software project, and that is true. It isn't entirely clear to me how it could have been otherwise, and moreover, it does not render the book unuseful. The father Berenstein Bear made an industry of showing the little tyke bear what not to do. Well, same here. Plus, the wandering captures the spirit of the endeavor.
What I do not sufficiently hear in the review-o-sphere is the dramatic turn the book makes at chapter 9, into the history of software development methodologies and personalities. For 75 pages (a bit less than a quarter of the book), we get a fine tour of software craftsmanship over the decades. Along the way, every major title in software development (and not a few minor ones) is cataloged and discussed. This discussion and the attendant bibliography is easily worth the price of the book (and maybe worth the cost of reading the other 75% of the book),
One issue the author had was when to stop the book, as the software never came to any cohesive point. So it just stopped, just like the software project did a couple of years later.
I think the title was a poor choice. It has nothing whatever to do with the book except a tangential reference, and a great opportunity to say something conclusive about the project was lost. I suppose that the jury had not yet completely returned on the project when the book went to press, however, "The Road to Nowhere: Hazards of Following the Pied Piper" or "Good Money After Bad: How and Idea, a Bucket of Money, and a Dynamic Personality Weren't Enough," would have been a lot more on point.
Learning about Kapor, who founded Lotus Development Corporation and designed the wildly popular spreadsheet software, Lotus 1-2-3, was in itself enough to make this book a worthwhile read for me. Nevertheless, "Dreaming in Code" fails in its major objective. The faults of the Chandler project - chiefly, "paralysis by analysis" - should have been glaringly obvious from the start, in 2001. It is little surprise that a project will be late or worse when it lacks a clear objective. What is atypical about Chandler is that it took so long to peter out. Its failure is a reminder that having a sugar daddy and no deadlines is more a prescription for failure than success.
Rosenberg monitored the work on Chandler for three years before he called it quits and wrote his book. Since then, Mitch Kapor has left the project, and withdrew funding in 2008. Chandler is available for download, but shows no sign of being the world-changing software tool that it was hoped to be.
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.
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 you are thrust into a chapter-long recantation of some particular aspect of historical software engineering design. I'm sure this was done in order to appeal to the luddite-fringe in the book crowd, but to seasoned veterans this is just plain frustrating. Sort of like sitting in your college calculus class and then suddenly having the teacher talk about the basics of addition. Which ties me to the problem with the book.
If you are going to tout the book as the next generation successor to Soul of a New Machine, at least follow the phenomenal lead set by Mr. Kidder and tell the story about the people behind the machine--that's what sells and lasts the test of time. Technology comes and goes but it's the story of people which remain etched in time.
To paraphrase, sorry but Dreaming in Code, you are no Soul of a New Machine. BTW, the end story told on the last two pages is priceless.
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.
Kidder's book was successful because it reached a definite conclusion: the new machine was completed, and it met its goal of beating the VAX. During the course of the book, the reader vicariously became a hardware hacker, a power tool, pedal to the metal - you could feel the tension, the long nights into morning, the frustration.
In contrast, Chandler does not get finished in Dreaming; it's barely alpha test. Of course that's not the author's fault, but in that respect alone this book falls far short of Kidder's. As far as style, Rosenberg is not nearly as effective as Kidder in conveying to the reader the mentality, the spirit, the verve, the je ne sais quoi that embodies the software hacker. And I say that as someone who has had to hack software to the wee hours. In other words, I know what it's like, and Dreaming didn't really bring back wistful memories of the quest to get it working; how would a lay person get it?
That said, Dreaming is a start, but IMHO it still leaves a void for a book that really is a software version of Soul of a New Machine.
Mr. Rosenberg delves beyond the Chandler Project to put this effort into perspective with the history of computer software development. He tries to show why, despite the advances in computer hardware and the development of advanced programming languages, the creation of a new application remains so challenging. He shows how many of the challenges facing software development in the 1960's as outlined by Fredrick Brooks in "The Mythical Man-Month" are still facing programmers today, such as, adding more programmers to a project behind schedule, only makes it farther behind schedule. He explains why managing creative programmers whether it is for the Chandler Project, or for the FBI's Virtual Case File, is terribly difficult and can frequently lead to abject failure.
"Dreaming in Code" is written as much for the non-technicial reader as for a technical one. It does not require an advanced degree in computer programming to be understood. It is more of a epic travelog through the shoals of modern software development. Can the visionary communicate that vision to managers and programmers so they can bend technology to create the application? In some cases they can and in others the vision must be modified.
The reason I did not give this it's fifth star is that the story remains incomplete. This is not the fault of the author, but rather due to the delays in completing the Chandler project itself. A preview version of the Chandler application is due out this Spring, several years beyond the original schedule. But dispite this frustration, I would recommend this book to anyone interested in the complexity of technology development.
But for my surprise I found this book really good in his own way. It really describes via examples and a 'journal'-style events that had happened in the past with me and most likely anyone that has been involved with software development in a professional manner.
Some of the ideas and facts exposed can either let you down and make you think twice about creating software or at least, what was in my case, to rethink about the way you have treated the software industry in order to not repeat the same mistakes.
I consider a must have book for anyone that wants to create software no matter which technology/language/platform or area (programmer, architect, manager etc).
Frankly, the book wasn't very intense, and I think the other reviewers nail the reason on the head: The author picked a poor start-up to follow, especially because there were no VCs or other outside funding sources to answer to. It's Kapor's money, so if it takes another year and he's OK with that, fine. I have worked at a company similar to this and it is definitely different from an outside funded company.
I expected an intense start-up story based on the title, but having finished the book, I find the title misleading. It's more like "Dreaming in Mediocrity" or "Dreaming of Making a Decision, One Day".
As other reviewers mentioned, the author diverges from the story in the middle of the book to ramble about many things. I'm not really sure what the point of this divergence was, other than, perhaps to cover some topics of interest before the author admits in the last 20 pages that he had to give up following this company because they were taking too long.
The book is a good read, but I'd love to see a book about some more hardcore start-ups and more hardcore bugs (low level SCSI corruption, multi-threaded nightmares, trying to scale a wildly growing service such as PayPal, etc.) Such a book might have a more limited audience, which brings me to another point: I never really figured out who the audience for this book is. The book introduces many software topics at a high level, but I'm not sure someone who wasn't familiar with programming would get much out of these sidebars.
These points aside, the book is well written, though somewhat choppily organized. Reading about a losing company isn't as fun as reading about a winner, but at least one lesson is clear: Even experienced software folks have trouble shipping code. Strong management is key and this company didn't have that.