jump to navigation

“Dreaming in Code”: book review May 19, 2007

Posted by gcorbin in Review.
add a comment

Many times, in my career as a programmer, I’ve found myself lying awake at night thinking about the code. My thoughts would slowly fade away as I began to fall asleep. That’s when it would happen. That’s when I realized that I’ve been thinking so much about the code that I started to dream about it. I would be “Dreaming in Code”. After reading this book, I’m sure that I’m not the only programmer that dreams in code. The author of this book, Scott Rosenberg, begins this documentary by discussing his experiences as a programmer. He describes the excitement and frustrations of one of his first programs, a game called Sumer, which he wrote some extensions for. He raises the same questions that all programmers have been asking since the dawn of time. Why is creating good software so hard? He then moves on from chapter 0, to begin following a company named OSAF. He chronicles the process that they go through as they attempt to create a new product called Chandler. This product is to be the next ‘killer app”. A P.I.M (Personal Information Manager) that does not limit the type of data or how that data is organized. The main goal of Chandler is to remove the limitations of what, where and how our personal data is managed. “To tear down the silos”, as the author puts it. This story revolves around a software pioneer named Mitch Kapor. His big contribution to software engineering came in the form of the company he founded called Lotus and a great application he created called Lotus 123. His passion for software engineering shows in chapter 2 as we follow his early days at Lotus all the way through to his departure in the late 80’s due to his uneasy feelings about creating such a large corporate environment. Even with the great fortune and success that he had at Lotus, he could not find happiness within his role there without the unrestricted freedom he had when the company was a startup.

The author then takes us back in time for a bit to explore some of the greatest failure in software history. We explore the failures of the FBI and FAA software projects and move on to look at some of the largest software crashes of all time.

In chapters 3 through 5, we begin exploring the design decisions that the managers, designers and engineers at OSAF make to start work on Chandler. The author follows their story as they decide which language and tools to use. We see the OSAF team force the first 0.1 release of Chandler due to a purely time-based schedule. We move on from here to reflect on several past interview with software greats such as Linus Torvalds, creator of Linux, and James Gosling, creator of Java. We explore their opinions on the difficulties in software engineering and personal feelings on the open source movement. By the end of chapter 5, we find that the OSAF crew is flip flopping on many of the design choices they started out with and ultimately, it will cause them to fall further and further behind schedule.

            In chapters 6 we get an inside look at the trials and rewards that programmers face as they attempt to implement their projects design and craft it into work of art. One of the common follies that we explore is the decision to “Build” or “Buy”. Since most programmers see the building of a new application as a form of art, it’s difficult for them to accept foreign piece of code and integrate it into their own. Most often, if given the choice and time, many programmers will give a whole pile of excuses as to why it would be better to “Build” rather than “Buy”. Not to say that “Buying” doesn’t have its own problems, but in most cases this can be a big time saver.

In chapter 7, we find our OSAF team choosing to “Build” a framework for generating their User Interface. One can only wonder how much time might have been saved if they had only utilized what already existed.

In chapter 8, the OSAF team had decided it was time for reorganization. Kapor removes himself as CEO / Project manager and they hire some new people. The surprise here is that when these new people come into OSAF, Kapor allows them to radically change the design of Chandler, which is now 2 years underway. I suppose this shouldn’t be a shock, as new people always bring new ideas, but to find that the project’s CEO / venture capitalist would allow this was quite a surprise. The chapter comes to a close with the OSAF crew on a new feature/time driven schedule, already deeply behind it, and learning that Google has launched a new product called GMail, which includes many features that Chandler is driving to deliver.

Chapters 9 and 10 the author diverges away from following OSAF and begins to review project management and it evolution within software history. We spend some time discussing the foundation of the Software Engineer Institute and how the CMM standards evolved into what they are today.

In the final chapter, we revisit the OSAF team to find out what type of progress they had made, have they caught back up with their schedule? Or have they slipped away into the archives of software irrelevancy? I don’t want to ruin the ending for anyone, so you’ll just have to read the book to find out.

Overall, I really enjoyed this book. It comforts me to know that I’m not the only programmer that experiences all the joys and pains of my profession. There are many great references to classic books and essays on software engineering that all programmers should be required to read. I felt that I was able to enjoy the journey of the OSAF team as they struggled to wield there skills to sculpt a beautifully thought out and designed work of art. I also felt that there were many lessons that I learnt and new ideas that I will be able take with me to apply in my own endeavors.

If your interested in thi book, you can find more info about here.