Regarding "Dreaming in Code"

I just finished reading "Dreaming in code" by Scott Rosenberg and I must say that it was an interesting read. Rosenberg writes as one who is clearly technically savvy, in the sense that he can get around his computer proficiently, but is a clear outsider to the field of software engineering. This externalness is actually refreshing, giving an interesting perspective as an outsider looking in. This is interesting precisely because it is rare: most of those outside of programming would rather look away than in. I get the feeling most would rather swim in raw sewage than in code. The book follows the journey of Mitch Kapor and his team in the early days of the Open Source Applications Foundation (OSAF) and the creation of its first application, Chandler. Along the way, Rosenberg makes user-friendly detours into programming history and concepts.

The amateurism showed through in a few parts. For example, there was Rosenberg's description of object oriented programming. The description sounded like the author had a Java programmer whispering in one ear and a Smalltalk-school professor whispering in the other. The result is some text that isn't entirely wrong, but doesn't describe object oriented programming, either as it is in theory (Smalltalk and academia) or as it is in practice (Java). Ironically, Rosenberg should have picked up on this as he later quotes Alan Kay, the father of object oriented programming as saying "Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind." That should have given him the clue that he needed to probe a little deeper.

Of particular interest were the chronic problems that Chandler had while getting up and running. The usual problems that software encounters were discussed. Things like an uncertain design, personnel changes, technology changes, the uncertainty of estimates, the fact that software is not infinitely malleable were all addressed as general problems for software slippage and even for some of Chandler's problems. Interestingly, I thought that the most important problem with Chandler's development (as portrayed in the book, which is my only real source on the matter) was the dream man himself: Mitch Kapor.

It seems like an odd charge to bring, given some of Kapor's other successes, from the design of Lotus 1-2-3 to the chairing of the Mozilla board. Kapor seems like the kind of man who would know his way about software development. The problem seemed to lie in his style of leadership or, sometimes, his lack thereof. For example, there are several large sections show technical debates in which Kapor himself took a side role and basically waited to see what consensus would arise. Indeed, Kapor himself lauds the project's democratic style. Somehow, we programmers have an almost endless capacity for debate, even pointless debate. Most leaders or managers are too heavy handed, not letting good people get work done, but bogging them down in red tape and superfluous micromanagement. Kapor was too light handed. He did not step in to push the project along, but let it languish.

Another problem you see (which may have even been acknowledged by one of the departed developers) was that during the timeframe given, Chandler refused to be either a Cathedral or a Bazaar. The book discusses Eric Raymond's famous essay and Kapor's interest in it. However, when OSAF began work on Chandler, the code was released, but the real work, especially design work, was taking place in a meeting room in California. Even after a wiki was added, the book mentions one of the team members entering notes from the meeting into the wiki. The problem with doing this is that it takes the weaknesses of both approaches: you neither have the protective wall of the Cathedral nor the open marketplace of the Bazaar.

Ideally, Kapor would not have hired anyone up front, but would have sat down with Python and wxWidgets (the selected technologies) and banged out a simple version himself. Then, released it on the web in true open source mode. Then, if he felt it necessary to move the vision along, hired developers. The ironic thing is that, at the beginning, the project received a lot of Slashdot attention. It is entirely possible that, had Kapor taken this route, he could have had his dream and perhaps without hiring anyone or taking out a bunch of space.

Overall, it was an interesting read there. Reading the history of a software project is kind of like reading folklore from the land of Geekdom. It was also of interest to see how the whole thing looked when watched and researched by an outsider to the field.