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

Mr. Rosenberg may not have picked the most typical software project for this case study but the similarities in delays, defects, and disorder of so many other software projects is uncanny. Perhaps it is because there is no such thing as a "typical" software project. Every problem space and every group of people has its own distinctives that make each project appear unique. References to Brooks' monumental 1972 work, The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition), are numerous and with reason - little seems to have changed in the 3 decades since that work. As fast as software design methodologies change, the technology that underlies it changes faster yielding new challenges. It is an industry that seems to outgrow every discipline designed to control it and there seems little hope it will be tamed anytime soon. The implications of our world becoming more and more dependent on such shakey ground is frightening and costly. Rosenberg's work is a good reminder to the software artisan/engineer (we cannot even define the best monicker for this discipline) that the more things change, the more they remain the same. Rosenberg would be a worthy followup study to Brooks for anyone involved in the software industry - designers, managers, requirements authors, and more. Begin with Brooks and then read Rosenberg to understand the scale of the challenges. For the non-technically-oriented reader, Rosenberg paints an entertaining picture of the past characters and movements that have shaped software design over the years. He looks briefly at some topics such as the psychological makeup of the typical software designer and how that affects the industry but also at the long history of trying to decide if software is more an art or a science. It is a question that baffles us yet today. It is unlikely, Rosenberg seems to admit, that anyone will have a breakthrough idea to resolve this growing problem. Rosenberg may not have offered the solution but he has done a fine job of describing the problem for the rest of us - technical or not. As we grow more and more dependent on software every day, it would not be melodramatic to claim that our future depends on resolving the issues involved in the process of creating it. Rosenberg has provided a good description of the current state and provides a challenge for fixing it. _Dreaming in Code_ may be another of those milestones in software design history to help us guage our progress one day. Perhaps it will be another of those monuments like Brooks' that remind us how little progress we have made. Management seems intent on finding the illusive defect-free programming methodology but perhaps they would do better to understand the concepts of dealing with an ever-changing environment of human activity. Human activity will always remain prone to error and software managers would do well, in the view of this reviewers, to consider the works of Ch

It's easy to see why Dreaming in Code has been such a hit. I just finished reading it and found it to be an extremely well written insider's look at a software development project. Even if you're not that interested in the story behind the still unreleased Outlook killer, otherwise known as "Chandler", you'll find this to be a great overview of why the whole application/system development process can be so darned complicated. In fact, you might find yourself wondering how any development team ever manages to get any product out the door! Dreaming in Code is the story behind Mitch Kapor's latest dream of inventing a much better contact management tool than the world has ever seen before. You can keep up with the team's progress via their website and blog, but if you're really curious and want to know the full history, you need to read the book as well. There's also a companion website for the book at [...] it's full of great resources and an excellent example of how all book websites should be built. Scott Rosenberg does a fantastic job of explaining the challenges, dilemmas, decisions and everything else that trips up most software development projects. It took me back to my days, long ago, as a programmer writing code for point-of-sale systems at NCR in the 1980's. It's funny (or maybe not so funny) how most of the same problems that plagued the teams I was part of 20 years ago still crop up on a regular basis today. In fact, that's one of the more interesting aspects of this book and one that Rosenberg covers well by going back even further into the 1960's and IBM's System/360. Here are a couple of excerpts that I found to be most insightful, the second of which is also quite relevant for those of us in the tech book publishing business: "Chandler was no different from the great majority of software projects. It's rare for a group of software developers to work together on a series of projects over time; in this they are less like sports teams or military units or musical ensembles and more like the forces of pros who assemble to make a movie and then disperse and recombine for the next film. So, while individual programmers and managers may carry with them a wealth of experience and knowledge of techniques that served them well in the past, each time they begin a new project with a new team, they are likely to end up pressing the reset button and having to devise a working process from first principles." Joel Spolsky is quoted in the book and reports this about development methodologies: "...the majority of developers don't read books about software development, they don't read web sites about software development, they don't even read Slashdot. So they're never going to get this, no matter how much we keep writing about it." What I liked best about this book though is that it's not just for programmers and other techies. Rosenberg does a great job of writing everything in layman's terms so that even the most complex issue i

Based on my 25 years of experience as a software developer, I found Dreaming in Code to be an astonishingly correct depiction of the current state of software development. In documenting the development of Mitch Kapor's "Chandler", a personal information management (PIM) project, Rosenberg reminded me of prior projects which went on interminably, as they slipped into "software time", where long-term software projects can get trapped in endless cycles of change, development, testing and fixes. Every developer should find this story line distressingly familiar, even comical, as the "Chandler" managers make the same kind of project management mistakes which have doomed countless other projects. Although the "Chandler" story is easily recognizable to software professionals, Rosenberg tells this tale from an outsider's perspective, allowing him to simplify this highly complex subject and appeal to anyone who cares about computer software and its creators, managers and consumers. In a first for a journalist, Rosenberg interlaces his "Chandler" story with a brilliant tutorial on the history of software development, explaining this highly technical subject in ways which the non-technical can understand. But Rosenberg goes much further than this. In clear terms that can be understood by practitioner and layman alike, he explains the sad truth that the majority of software projects can end up like "Chandler", with budget overruns, schedule delays, endless bugs and missed requirements. All these insights are strikingly similar to the ones in the landmark book by Frederick Brooks, The Mythical Man-Month, which described the difficulties found in IBM software projects 30 years ago. Despite all the technical advances since then, the problems with managing software development projects have remained largely unsolved. My hope is that Dreaming in Code will become a resource which can help enlighten all stakeholders to better clarify and coordinate software projects for the betterment of all. Five stars for bringing such a difficult and important subject to the general public.

You know the old joke about how you'll never eat sausage again once you see how its made? "Dreaming in Code" doesn't go so far as to convince one that all software development efforts are car crashes. But it does a wonderful job of showing exactly what happens when you take a small group of bright people, a really good idea, throw them into a loft and say "create the next great product". Having been involved in a number of startups I can say that I recognize all of the people and all of the successes and all of the mistakes these guys make. If you want to see what its like inside a startup I couldn't recommend this book more.

Ansel Adams wrote, "There is nothing worse than a sharp image of a fuzzy concept." And such is the case with the Chandler project. After four years of development, they have delivered only a 0.6 release with no general availability in sight. In Dreaming in Code, author Scott Rosenberg follows a group of programmers tasked with creating a new product over a three-year stint. Along the way the book explores disciplines in development (and the lack of), the history of computing (particularly its truths and folklore), and explains why software engineering isn't a science but an art. A common misconception even among developers is that software is similar to construction when, as becomes clear in the book, developing software is more like cooking. Programming methodologies are as plentiful as cookbooks but both are limited by the realities of artistry. A chef can make miracles from a pantry full of ingredients; a cook cannot. If you're involved with a development team as a marketer, there is much here that will illuminate your team's dysfunction. Rosenberg reintroduces us to concepts that have been known since The Mythical Man Month and The Soul of a New Machine but apparently not understood, remembered, or believed. Strongly recommended.