Jim Morris's Thought of the Week (or month, or year, ...)
Tuesday, January 16, 2007
Why Basecamp Doesn’t Work
I often run ad hoc projects using email. We all use the “reply-to-all” command and attach Word and Excel documents. As a project extends and grows, this method begins to lose its effectiveness. Versions of files get confused, and a new arrival can get acclimated only by reading a lot of wandering mail, if one can even find it. Basic follow-up is difficult.
Embarking on a project involving twenty or thirty people from all over the place, I decided to try Basecamp. It is a minimalist, web-based management tool supplying messages, milestones, to-do lists, and whiteboards—all delivered in a wiki-style, free-for-all package. Its greatest attraction is the ease with which one can get started and introduce it to others.
Basecamp’s Achilles Heel is that it cuts us off from direct use of all our favorite tools. I want to use my chosen editor, mail client, and calendar to participate in this project. So does every other participant. Basecamp has its own wiki-style editor, distribution list, message archive, calendar, etc. It does its best to communicate with the outside world: messages are emailed and documents are exported in many formats.
Nevertheless, I find that the very notion of being inside or outside Basecamp—requiring importing or exporting—is a problem. At least, it seems to be inhibiting uptake by most people on the project. All of them are virtual volunteers who have many other things to do and preferred ways of doing them. Basecamp’s walls, permeable as they are, are simply too much for us. The biggest problem is that things scheduled in Basecamp don’t propagate to people’s calendars.
I’m sorry to be picking on Basecamp because it is a very nice thing. Virtually every collaboration tool I have tried for the past twenty years has had the same problem, but worse. Its permeability problem is endemic to our reigning software environment. I think the general problem is just too hard to attack, so I’m just focusing on this single tool.
The general problem has two obvious solutions: everyone use Microsoft standard applications or work out general inter-application communication protocols. The former might happen to us if we can’t manage the latter. Is the latter what they mean by “service-oriented architecture?”
The last working inter-application communication protocol I saw was Unix pipes. The designers decreed that every application swallow and disgorge an ASCII stream. The rationale for this was that every application began life talking to a human who was typing characters and reading TTY output. Therefore, application linking could be done through those interfaces that already existed for speaking to humans.
This worked great, but it was overwhelmed by the display-based interface. Everyone has been looking for the display-oriented equivalent of the ASCII stream every since—everyone except the author Neal Stephenson, who once wrote a book-length rant on why we should all go back to the command line interface. He has a point, but we won’t go back.
The problem is that the display interface is so much richer than a stream. However, HTTP took a stab at a narrow, finite protocol. Dumb questions: Is there a way to create a web page that calls other web pages like subroutines using HTTP. Is that what AJAX does?
posted by Jim Morris @ 1:34 PM