clay on situated software

Everyone and their mother (referenced by design) will be pointing to Shirky's latest, Situated Software. And for good reason -- this is one of his best.

First, it's great to finally read something about social software that isn't about LinkedOrkutsers or collaborative wikis, but about small tools that have affordances only for the immediate communities they serve. Second, he calls out something critical that's being lost in the outsourcing / offshoring noise -- that "there's also a lot of downsourcing going on, the movement of programming from a job description to a more widely practiced skill." And third, there's a very intriguing idea at the end of the piece re. eliminating the expectations that apps will/should live forever:

Expectations of longevity, though, are the temporal version of scale -- we assume applications should work for long periods in part because it costs so much to create them. Once it's cheap and easy to throw together an application, though, that rationale weakens. Businesses routinely ask teams of well-paid people to put hundreds of hours of work creating a single PowerPoint 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.

Indeed, as a matter of effect, most software built for large numbers of users or designed to last indefinitely fails at both goals anyway. Situated software is a way of saying "Most software gets only a few users for a short period anyway; why not take advantage of designing with that in mind?"

In most corporate environments, even the little apps that get built do end up lasting forever. And become more and more difficult to rip out and replace with the new new thing. Assuming that the tools do migrate to a point where it's "non-programmers" that are building applications, should micro-apps designed for a few users be built with a "good until" expiration date, by design?

Comments

[Greg Knauss]

Apps live forever because problems live forever. Declaring a program dead doesn't make the task it was performing complete. (Witness the howls of protest whenever code is retired without the replacement being ready.)

That half-assed hack that you threw together two years ago and is still running _is_ still running because the problem that you were working on still exists. Declaring the software dead doesn't change that. I've got a friend who would like nothing better than to get out from under a teetring mountain of Excel marcos, but can't, because then his business will stop.

How all this relates to Shirky, of course, is that, yes, building an application appropriate to your audience is a good thing. But bad design is still bad design, and you'd better think about how long the problem is going to live before you start deciding how long the solution will.