Situated Software

software designed in and for a particular social situation or context.

"Instead of engineering an entire site for all foreseeable features it might need, the situated software models means having software programmers working alongside content folks to adapt to the conditions, needs and growth of the community. Slashdot did the same thing in developing meta-moderation. Wikipedia developers (one paid, and many volunteers) rewrote features as the community grew and vandalism was more rampant and sophisticated." (http://citmedia.org/blog/2006/03/05/digg-graduates-towards-slashdot/)

Description

From Clay Shirky at http://www.shirky.com/writings/situated_software.html:

“Part of the future I believe I'm seeing is a change in the software ecosystem which, for the moment, I'm calling situated software. This is 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.

I see my students cheerfully ignoring Web School practices and yet making interesting work, a fact that has given me persistent cognitive dissonance for a year, so I want to describe the pattern here, even in its nascent stages, to see if other people are seeing the same thing elsewhere.

Users By The Dozens

We've always had a tension between enterprise design practices and a "small pieces, loosely joined" way of making software, to use David Weinberger's felicitous phrase. The advantages to the latter are in part described in Worse is Better and The Cathedral and the Bazaar. Situated software is in the small pieces category, with the following additional characteristic -- it is designed for use by a specific social group, rather than for a generic set of "users".

The biggest difference this creates relative to classic web applications is that it becomes easy to build applications to be used by dozens of users, an absurd target population in current design practice. Making form-fit software for a small group of users has typically been the province of banks and research labs -- because of the costs involved, Web School applications have concentrated on getting large-scale audiences. And by privileging the value that comes with scale, Web School applications put other kinds of value, particularly social value, out of reach.

We've been killing conversations about software with "That won't scale" for so long we've forgotten that scaling problems aren't inherently fatal. The N-squared problem is only a problem if N is large, and in social situations, N is usually not large. A reading group works better with 5 members than 15; a seminar works better with 15 than 25, much less 50, and so on. This in turn gives software form-fit to a particular group a number of desirable characteristics -- it's cheaper and faster to build, has fewer issues of scalability, and likelier uptake by its target users. It also has several obvious downsides, including less likelihood of use outside its original environment, greater brittleness if it is later called on to handle larger groups, and a potentially shorter lifespan.

I see my students making some of these tradeoffs, though, because the kinds of scarcities the Web School was meant to address -- the expense of adequate hardware, the rarity of programming talent, and the sparse distribution of potential users -- are no longer the constraints they once were.” (http://www.shirky.com/writings/situated_software.html)

Discussion

Clay Shirky:

“Situated software isn't a technological strategy so much as an attitude about closeness of fit between software and its group of users, and a refusal to embrace scale, generality or completeness as unqualified virtues. Seen in this light, the obsession with personalization of Web School software is an apology for the obvious truth -- most web applications are impersonal by design, as they are built for a generic user. Allowing the user to customize the interface of a Web site might make it more useful, but it doesn't make it any more personal than the ATM putting your name on the screen while it spits out your money.

Situated software, by contrast, doesn't need to be personalized -- it is personal from its inception. Teachers on the Run worked this way. Everyone knew that Paul and Keren built it. You could only rate Clay and Marianne and Tom and the other ITP professors. You didn't even know it even existed unless you were on the ITP mailing list. The application's lack of generality or completeness, in other words, communicated something -- "We built this for you" -- that the impersonal facade of RateMyProfessors.com doesn't have and can't fake.

One of my students mentioned building a web application for his mother, a schoolteacher, to keep track of her class. If you were working alone, unpaid, and in your spare time, there's no way you could make an application that would satisfy the general and complete needs of schoolteachers everywhere. You could make one for your mom, though.

Small, purpose-built apps have always existed, of course -- learning BASIC used to be a rite of passage for PC owners, and data intensive institutions like investment banks and research labs write software for small groups of users. Now, though, the combination of good tools, talented users and the internet as a social stage makes the construction of such software simpler, the quality of the result better, and the delivery to the users as simple as clicking a link. The design center of a dozen users, so hard to serve in the past, may become normal practice.

So what happens next? If what I'm seeing is not transitory or limited to a narrow set of situations, then we'll see a rise in these small form-fit applications. This will carry some obvious downsides, including tying the developers of such applications to community support roles, and shortening the useful lifespan of the software made in this way.

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; why not take advantage of designing with that in mind?"

This, strangely, is a kind of progress, not because situated software will replace other kinds of applications, but because it mostly won't. For all the value we get out of the current software ecosystem, it doesn't include getting an application built for a handful of users to use for a few months. Now, though, I think we're starting to see a new software niche, where communities get form-fit tools for very particular needs, tools that fail most previous test of design quality or success, but which nevertheless function well, because they are so well situated in the community that uses them. “ (http://www.shirky.com/writings/situated_software.html)

More Information

Shirky’s article has many examples from his teaching practice. See at http://www.shirky.com/writings/situated_software.html