« Activity Partners for Activists |
Main
| Noise Society or Network Society? »
March 31, 2004
Situated Software
Posted by Clay Shirky
I just published a piece called
situated software, about a pattern of software creation I think I'm seeing among my students at ITP:
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.
It's a set of observations about a change in programming practices and costs, but also about building software that is situated in an existing community, and takes advantage of that community's behavior in a way that impersonal Web applications can't.
Comments (4)
+ TrackBacks (0) | Category: social software
- RELATED ENTRIES
- › Spolsky on Blog Comments: Scale matters
- › "The internet's output is data, but its product is freedom"
- › Andrew Keen: Rescuing 'Luddite' from the Luddites
- › knowledge access as a public good
- › viewing American class divisions through Facebook and MySpace
- › Gorman, redux: The Siren Song of the Internet
- › Mis-understanding Fred Wilson's 'Age and Entrepreneurship' argument
- › The Future Belongs to Those Who Take The Present For Granted: A return to Fred Wilson's "age question"
1. Frank Ruscica on March 31, 2004 10:32 AM writes...
Seems like the social process analogue to MIT professor Von Hippel's finding that 100% of business process innovations encoded in software are developed by domain experts, not sw vendors...
Permalink to Comment2. Zbigniew Lukasiak on March 31, 2004 12:33 PM writes...
Yeah - software should be written for a target population and when software is easier to write (better hardware, languages and libraries) it might be justified to write software for smaller targets.
Permalink to Comment3. Lucas on March 31, 2004 5:38 PM writes...
I admire your students' abject humility in stifling any ambitions they might have for the larger, more general applicability of the software they write. ;)
You make several interesting arguments in favor of highly targeted design, but I think by and large to formulate it as a trade-off between specifity and generality is a specious one.
Software is generally developed "in layers" precisely to address this trade-off. Here's how it works: a designer is given a bunch of use-cases. He then has to abstract them, meaning he has to tally their similarities and differences. The functionality represented by similarities goes on the bottom, as base level services. Differences go higher up. Now if someone wants to add a use-case (assuming it follows the same pattern of abstraction as the previous use-cases) all he has to do is add a higher level module to the common base level. Wala. Customization.
To say that a tool as general as MySql (or any other database) should be the jumping off point for social software development is not good design in that it fails to address the large number of commonalities found in almost all social sofware.
Componentization, integration, separation of interface from data, user-centric design, all these ideas are still valid even if what you call "Web School" design has, it seems, idiotically chosen to ignore them. We are in danger of a large number of web developers losing their sanity the next time they have to write another user-logon. Your students are lucky they haven't (yet) had to deal with this.
The one almost fatal argument you make against social software design "in the wild" is that because designers don't know each other personally there is not the necessary working raporte and teamwork. I agree this is not an easy obstacle to overcome, and who knows if there exists a social software environment with the necessary tools to overcome the fear, distrust and passivity around strangers that have bled in from the real world. I think there does, but there is only one way to find out.
We need to "think big" not only for the obvious reason of developing a general social software architecture that doesn't turn people away in disgust after a few months, but also because the biggest challenges attract the best people and stir up the most energy.
Permalink to Comment4. Nick on April 1, 2004 6:35 AM writes...
Great essay, and it makes me think about some of the barriers we're up against in our own project (Urban Tapestries) in a completely different way...hey, if social software may be difficult to scale beyond appropriate situations, then could be we've got a lot of features instead of a lot of bugs!
I also have to say that your analysis completely reminded me of the days of Hypercard in the late 80s/early 90s -- a scripting program which was much easier for teachers and other subject-area experts to learn than mySQL or PHP or Perl will ever be. It was always pooh-poohed by "experts" (read: software developers and large companies), but thousands of real people put it to excellent use in real-life situations.
Permalink to Comment