(2004-03-30) Shirky Situated Software

Clay Shirky on "Situated Software", designed in and for a particular social situation or context. This way of making software is in contrast with what I'll call the Web School (the paradigm I learned to program in), where scalability, generality, and completeness were the key virtues. This sounds a lot like the old days of HyperCard, MsAccess, spreadsheet macros, though these WebApp-s have the advantage of being easier to roll out to multiple users. (Update: and the code is separated from the data, which offers the potential of future apps built by different people in different languages having some leverage of history...)

But still some good bits as apply to small-scale Social Software. Time and again the groups came up against problems that they solved in part by taking advantage of social infrastructure or Context-sensitive information that wouldn't be available to adherents of the Web School... Web School software ignores this kind of knowledge, because it is hard to make explicit... There is another strategy, however, analogous to asking the user to recognizing icons; the designer can simply assume the group has a certain capability, without needing to recapitulate it in code. If you have an uncollected payment in a communal buying pool, the software can kick out a message that says "Deadbeat alert. Deal with it." A real world group will have some way of handling the problem, usually through moral suasion or the threat of lost reputational capital, or even, in extreme cases, ostracism. This is no different than what happens in offline groups every day, but the solution feels wrong, in Web School terms, because those web applications can't assume there is a tacit reputation system. By relying on existing social fabric, situated software is guaranteed not to work at the scale Web School apps do, but for the same reason, it can work in ways Web School software can't.

• cf social warrens

Businesses routinely ask teams of well-paid people to put hundreds of hours of work creating a single MsPowerpoint deck that will be looked at in a single meeting. The idea that software should be built for many users, or last for many years, are cultural assumptions not required by the software itself. Note this approach doesn't lend itself to Off Shoring...