Book Review: Dreaming in Code
Posted by
Kevin
When I was a kid, my parents had a simple system for paying bills. They had a cheap, plastic bill holder — a hunk of puke colored plastic with fins of various sizes rising from it’s base. Bills to be paid went on the left half of the holder, already paid ones went on the right, waiting for stamps. The bills themselves could be anything — actual bills from a real company, notes written on scraps of paper to remind my parents to donate to the charity of the day, even bank statements to serve as a reminder to move money form checking to savings, or vice versa. It worked very well for my parents and they still use it — having replaced the ugly bill holder with slots in their elegant computer desk — to this day. It is also a system that is very hard to replicate in a computer.
Computers and human beings do not think the same way. For a human, concepts like “next Tuesday” and “a meeting every other week, on Thursdays” and “this piece of paper is both a piece of mail and a reminder to put a check in the mail on the 13th” are both easy to remember and easy to understand. The same is not true for a computer. Computers store data differently than the human brain and making certain associations is not as easy for programing languages as it is for human beings. This fact, that the human brain isn’t really a biological computer, is the cause of almost all frustration people have with software. We expect our tools to “think” in the same fashion we do, and they don’t. Dreaming in Code, by Scott Rosenberg, is is the story the failure of programmers and engineers to bridge the gap between they way we think and what our tools can do, using the Chandler project as an example.
I want Chandler, but I will probably never see it. As described in the book, the Chandler group wanted to a create a personal information manager that would store and manipulate data in a fashion much more similar to how we hold information in our brains. In traditional programs, data is separated into categories or “silos”. Email is one kind of data, and so goes in one spot. An appointment on a calender is another kind of data and so goes in another. But as we already discussed, humans don’t operate like that. That email form my boss is also a change in schedule. That status report is also a reminder that the widget problem needs to be solved before we can decide on a release schedule. That calendar appointment is also a mile high stack of paperwork I have to get done before the meeting with the security audit. In small doses, this is easy for me to remember. It is progressively harder to do the more I have to remember, which is why we use programs to help us remember in the first place. But due to the discrete nature of computer data, building in those kinds of relationships among disparate kinds of data is not easy to do. Eventually,you pay a price in performance, in data size and robustness, and in user experience. Rosenberg details how the Chandler team encountered and dealt with — or failed to deal with — those problems. He also, at appropriate points, ties in the decisions that the Chandler team made or fell into to past discussions and fads about the best way to create software.
This is an area where the book really shines. Making software is still hard to do. Its rare for a large project to come in on time, under budget, and with the original feature set. This has been true since the invention of large scale software projects, right after the Second World War, and millions of tress and billions of electrons have given their lives in the search for why this is so. Rosenberg ties the Chandler team’s current problems to discussion of programming efficiency and software engineering from the past, using their problems to bring to life the consequences of popular theories and methodologies of software creation. None of these methodologies or theories has been anything resembling a large scale success. There are many reasons for this, from the iinabality to accurately and objectively measure programmer performance (this is a rant of a separate post, but if you are trying to measure programmer efficiency by some measure like lines of codes or number of bugs reported or fixed, then you are setting yourself up for a colossal failure) to the difficulty in brining new people onto a software project. Rosenberg uses the individual experiences of the Chandler people to illuminate a given set of theories, weaving their personal frustrations and triumphs as a touchstone to a more academic discussion of the history and qualities of software engineering methodologies. It is a very effective tactic, the difference between telling you that Picasso could paint and showing you a print.
This is not just a book for programmers. Anyone who designs, writes code, or manages programmers will be well served by reading the book, of course. Rosenberg has written a kind of meta case study. Not only does Rosenberg highlight what went wrong and right (and much more went wrong than went right), he also highlights what those failures mean for various software engineering theories and methodologies. It is an illuminating look at the topic. But this is also a tail for everyone else. More and more of our lives our intimately tied to software. Everything from how we get our entertainment to how we do our work to how our cars’ safety systems function is dependent upon software. The soul of Rosenberg’s book is the struggles of the Chandler team members to take what happens in their heads and turn it into a software. Understanding that struggle is one of the best ways to come to terms with the failures, compromises, and limitations of the software that runs your life.
On comparing human brains to digital algorithms, I would say that the former’s strength is the ability to create ad hoc schemes on an as-needed basis with less than perfect accuracy, whereas the latter’s strength is the ability to enforce and execute deep, broad, complex schemas with zero loss of data and zero mistakes.
That said, with advances in heuristic algorithms and fuzzy logic (to name but a few), computers are becoming more capable in those domains where the human brain has traditionally been superior.
Of course the brain has the distinct advantage of having the five human senses as input media. I think the I/O gap will limit computers in certain applications longer than logic will.
Comment 1/29/2007
Ted
I thik that is a pretty good description of the differences, though I am less impressed with the progress of computers towards human style thought processes.
The I/O gap is an interesting point. I wonder if the differences between digital representations of sense and the actual input form real senses will make that much difference?
Comment 1/30/2007
Kevin, I’m not sure I would say that progress is being made towards human style thought processes, only that progress is being made towards being able to solve problems once only solvable by humans. I’m no expert in the field, but I’m not even sure that human thought processes are understood at a level that would allow duplication. I was optimistic that Deep Blue researchers and other computerized chess development teams would make real progress in this area, but when they decided to emphasize deep tree analysis rather than “feel”, I was disappointed. (I have not kept up with the field, so perhaps the emphasis has swung the other way recently..)
As for I/O, I think the analog nature of human I/O is vastly superior for certain classes of problem solving. And keep in mind that your bill filing example had a non-trivial physical element to it (reading, storing and retrieving the physical source data itself in the form of bills, checks, etc). Obviously a run of the mill computer is not equipped to directly manipulate the objects in your example so it is at an immediate disadvantage wrt a human-like UI. Fully automated warehouses do exist, so this specific problem has been “solved” on a large scale. If the source data is electronic in the first place (direct deposit, online bill paying, electronic banking, etc), then a digital solution can more than hold its own when compared to the traditional approach. Perhaps the physical world is changing to accommodate computers more rapidly than computers are changing to accommodate the physical world. Don’t know, I’m no Isaac Asimov…
Comment 1/30/2007