Clay’s new essay about what he calls situated software is very important. He is saying something new about software. I don’t think he’s run the idea to ground yet, which makes it even more fun.

He says the idea arose out of observing how his students executed an assignment – build a web app useful to our local community. The key insight was that some of these applications leveraged the complement of that assignment – build a web app that makes use of the local community.

Clay is close to asking a question that I’ve been puzzling about in various forms for the last few years. If we embrace that group membranes are a good thing then what kinds of things are possible inside of the membrane? It is hard to get to this question since so much energy is devoted to worrying over the membranes.

Clay frames that question by introducing the idea that there is a class of software that we could call “situated software.” Software that’s inside the membrane. Software that is dependent on the social contract or physical reality it runs inside of. He contrasts this with what he names “web school” software; i.e. software designed to run in cold cruel world, the globalized, firewall free world. That other world is, of course, interesting because the huge audiences create the chance at minimum of drawing on a huge sample space of users, and at the maximum of spinning up huge network effects. But yeah! Ignore that. What if I want to create software that empowers huge numbers of groups.

You can reduce what Clay’s saying in this essay; should you want to, by could mapping it into various conventional frameworks. Nothing wrong with that, as long as we take care to avoid killing the baby. Clay even does some of that in the tail end of the essay.

To some extent the idea is like personalization; i.e. software that adapts to it’s users. To some extent it’s like localization; i.e. software that adapts to the culture of it’s users. To some extent it’s like the things that we too casually repeat about the democratization of software development; i.e. that exciting things happen when users are empowered to author their own solutions.

I have gotten a degree of milage out of that last one. It gives you a long series of historical events you can pick apart. In each you can look at the social unfolding of what happens when software becomes more local. Lots of examples: minicomputers, PCs, spreadsheets, desktop publishing, drum machines, Hypercard…. Clay’s essay makes me tempted to go back and think about each of them again as a “localization event,” as enabling situated software to emerge. That’s more inward looking, which is what I want, than my usual model for these, (i.e. undermine the ivory towers).

He talks about how one of the student applications, a market making app, could skip having to build the module we find in market-makers like eBay which try to reify the buyer/seller reputations. His student’s applications could gloss over that because the local community’s reputation system was already available. It was in the platform so to speak.

That reminded me of how often I’ve encountered in-house one of a kind systems with no training materials what so ever. You do occasionally hear complaints about the lack of training materials (or doc); but generally the social networks of the organization are entirely sufficient to make up for the lack of doc. In fact I’m reasonably confident that the lack of doc often turns out to be something of a positive for both the local social network’s health and the applications in question. At minimum it makes adapting the applications easier. Documentation has a tendency to be like a coating of varnish making an application shinny and immovable.

Similarly he talks about another sample application where the problem of how to manage the dialog with your users is solved by physical presence. In what he calls “web school” or real internet application that problem bleeds into the entire can of worm around email preference management and privacy policies. Who in their right mind asks their bank to send them more email?

In the example he gives the students built kiosks put them in a public space, devices with minimal UI. Both the minimal UI and the use of public space are things I’ve noticed too. The first time I noticed it was with spreadsheets – an early success at software democratization. You would not believe the percentage of spreadsheets that contain no calculation what so ever; instead they live their lives as ritual artifacts placed on a table in a meeting. (information radiator, is a similar story).

Thanks Clay!