I’m a software engineer; at least, that’s what is says on my Master’s diploma. Over the years, I’ve written some beautiful code–but sometimes in languages known to no compiler. I sometimes wake up in the night, with a clear vision of some troublesome algorithm, and arise to my computer to make it take form. Alas, the clarity of the fugue state never seems to translate to actual performance.

Thus, it was with great anticipation I picked up a copy of Scott Rosenberg’s 2007 tome, “Dreaming in Code,” a tale of his three years spent documenting the gestation of Mitch Kapor’s latest venture, Chandler. Mitch Kapor, for those born since Windows, was the force behind Lotus-1-2-3, the “killer app” that put the IBM PC in the “most wanted” list in corporate America and thrust Microsoft and Bill Gates into the limelight. Kapor, who sold later sold Lotus to IBM, was pretty much set for life, but, like many of us who refuse to believe our early successes, no matter how spectacular, were our personal best, soldiered on. Rosenberg relates that Kapor, annoyed with having to tend his wife’s Exchange server just to support her calendar needs, set out to create another killer application to unseat the Microsoft Outlook/Exchange hegemony over enterprise scheduling and calendars. Chandler was to be that app, a cross-platform, peer-to-peer scheduler/calendar/to-do-list.

As I read through the book, the story unfolded in the early twenty-first century as if it took place in the 1960s, before Edsger Dijkstra’s “GOTO Considered Harmful” speech that started the quest to turn software construction into an engineering discipline. Chandler wallowed, seemingly rudderless, a realization of the old software engineering joke, “You need to start writing code now, so we’re ready when the requirements specifications arrive,” the Dilbertesque view of the world where it’s more important to be busy than to plan to be effective. Reading this was like watching a grade “B” horror flick, where the characters blithely blunder into dark rooms, where the audience knows they will be eaten by a grue (from an old text-only computer world adventure game).

Rosenberg takes time out in the middle of the book to review the history and state of the art of computer programming, putting the development of Chandler into perspective. I remember, in the same time frame, also gearing up to do cross-platform GUI programming but then realizing that the Web was evolving toward 2.0. Fortunately, I was the “lone programmer,” with no directives other than producing usable code, and could readily shift gears and change direction. My projects were, of course, not nearly so large or ambitious as Kapor’s.

I was struck by the explanation to non-programming readers that coding is, after all, writing, but, unlike literature, code is seldom read, and, often, is kept secret. When I taught computer science in the 1990s, I would exhort my students to find examples of good code and simply read it, to get a flavor of the style and flow. I like using intelligent editors, that “pretty print” your code as you type: if something looks ugly, or not as you expect, it is because it has an error in it. Chandler is written largely in Python, which a lot of programmers like because the proper indentation is part of the syntax. I’m not fond of constructs that depend on white space, so Python is one of those tools I keep in the bottom tray of the toolbox. Personally, I like Perl for system administration and grunt work, because it is “close to the machine” (to borrow Ellen Ullman’s phrase), like C, but simpler, like shell, with a lot of built-in power. For object-oriented projects, I like Ruby, though I find Ruby on Rails a bit confining. All through the mid-game of the saga of Chandler, I kept shouting at the pages, “No, don’t go that way, Rails is coming in a few months–it will change everything.”

I don’t know how the book comes out, because I’m still in the midsection musings, but I couldn’t wait: I downloaded Chandler, which, as I know now, actually did make it to Release 1.0. But, it’s a little behind in binaries, as many open source projects are, so I had to download the source and try to build it. Yes, the code is more nightmare than dream. As a cross-platform product, it doesn’t have that nice, clean autoconf/automake structure we like in our build packages. A few “Gee, I don’t know how to do that” messages from the ‘make’ utility brings us to open the code (that’s the meaning of “open source,” after all) and find the environment variables it expects that aren’t defaulted or set. Then, the build starts, but soon complains of missing dependencies. OK, we’re used to that, too, though a lot of package managers just take care of those. In this case, some of the dependencies were non-GPL’d packages that aren’t bundled in the distro archives, like BerkeleyDB, so we build that, then install the Ubuntu support packages that can use it. And, after a while, work drops into the mailbox. so we put that aside and work on paying stuff. To be continued…

What I see in this package is vindication that the “just write code and eventually we’ll have something that does what we want” school of design is not a very efficient way to do things. And, the lack of focus that resulted in a revolving door parade of developers on and off the project shows–The Python core, coupled with the C++ local widget sets, we can understand, from the design goals, but a list of almost every scripting language known to man (Perl, Ruby, Lisp) as dependencies? The concept of the program as a living, networked package is interesting. Like BSD, the source code is obtained from a version control server (using subversion), but then the build process jumps out and downloads a bunch more stuff with ‘curl’. Not too much different than modern package managers, but feeling really rough around the edges.