All three books are about teams of people pulling together to build something.  Having worked at Digital Equipment Corporation while the Data General Eclipse was being built (the subject of Soul of a New Machine) and at BBN, one of the builders of the early ARPAnet (i.e. the precursor to the Internet), those two books were quite interesting in the way they filled in gaps of knowledge I had picked up along the way.

Dreaming in Code is about Chandler, the initial project of the OSAF. It departs from the other two books by virtue of the fact that Chandler's story pretty well sums up all that can go wrong in software development while the other two books were about successes. That's not to say that Chandler is itself a failure. In fact, it's apparently still under active development, having hit version 0.7 in late 2006. So it's too early to tell.

The book describes the heady days when Chandler was a gleam in Mitch Kapor's eye, then moves along with the development of the software until mid-2006 when Rosenberg finally has to peel off and publish his book. The book itself interleaves a largely chronological narrative of Chandler's development with forays into the computer science background that helps frame the problems being faced by the development team.

I found the Chandler story to be riveting. It's a voyeur's dream, leading you into the pitfalls of software development, making you almost want to turn away, but feeling you have to watch to see what happens. It's as though the team makes every mistake possible, from not having a really clear idea of what they want to build (they have a vision, but nothing approaching any level of detail) to not jumping in and writing code, to a constantly shifting data model, a constantly shifting team with new members bringing in new ways to start over, to a seemingly conscious it-can't-happen-to-us-we're-different bumping into Brooks' Law and every other law.

The interspersed computer science bits are quite interesting, too. Brooks and his Mythical Man Month gets a lot of play, but there are forays into Simonyi's Intentional Programming, Lisp, Agile Development - you name it.

What does this all have to do with geospatial? Well, that's for you to decide. Are you, or have you ever been involved in a seemingly never-ending software development project that kind of sputtered along? I suspect some of us have.

Maybe a bit unfairly, the first thing that popped into my mind was the interminable pursuit of geospatial catalogs. Ever since there was geospatial data, people have been beating their heads against the sad fact that no one can find the data they need. As time goes on, it tends to be more and more certain that if you need some data, it's out there somewhere, but it's nearly impossible to find. Perhaps the longest running working group at OGC is the Catalog Working Group. I think it had already been formed by the time I jumped in in about 1994 or 1995. They are still at it. Meanwhile, many other geospatial catalogs have sprung up, some more successful, some less so. EOSDIS. ECHO. GOS Portal. EOLI. GCMD.  Now the OSGeo Geodata group is at it as well. So is GO ESSP. There was a brief flurry of excitement when Google dropped its hat into the ring with searchable KML.

The reason I say a bit unfairly, is because as functional units of built software, these things pretty much all work. As software projects, they are pretty solid efforts, with successful outcomes, but each embodies only part of the concept of allowing easy, universal discovery of geodata. There seems to be some kind of collective inability to crack the data findability nut. And in the end, that's what Dreaming in Code was all about. An earnest group of people, working really hard on a vision, floundering a bit here and there, generating some interesting snippets along the way, but in the end having to admit that the vision was not coming together as easily as it ought to.

The exercise for the reader? Figure out how to fix it!