Clay Shirky wrote an essay called Situated Software. He described a new kind of software
... designed in and for a particular social situation or context.
Situated software does not scale. It only works for the relatively small numbers for which it was designed.
As Shirky says
By relying on existing social fabric, situated software is guaranteed not to work at the scale [regular] apps do, but for the same reason, it can work in ways [regular] software can't.
To me, scaling is important. When I first used a windowing system in 1984, I did not keep many files in my home directory. It was easy for me to place their icons in various places in the window of a file manager. But eventually, I kept more files. My file manager window got cluttered. For example, after I came to realize I could not remember well, I learned to write `howto' files for myself. They added to my home directory since I did not put them in a subdirectory — I wanted to be able to reach them without having to type or put the cursor on the extra few characters of a subdirectory name.Worse, I could not remember the files' names. But I could, in those days, recognize them. So I learned to use the shell listing command, ls.
Then I learned to use dired in GNU Emacs. Dired is more efficient than a shell. But then it got so I could not always remember which contents went with which name. Did I refer to Zhou Enlai somewhere? If so, where?
So I learned to search with patterns among hundreds of files. Fortunately, Emacs automates passing options to Emacs's grep. This means I can ignore case distinctions, print the filename for each match, prefix each line of output with line number, and start patterns with a dash. In particular, this means I do not have to type `Zhou' with a capital `Z'. A lower case `z' will do. This is quicker. Many people do not care about this sort of thing, but I do. I see no reason for me to waste even a small portion of my life, if I can help it. (Often I cannot help it. Then I must live with it.)
It turns out that the reference to Zhou Enlai is in a file called
~bob/how-to-French-revolution and its complete contents are
Zhou Enlai is reputed to have said in the 1970s said that it is too soon to discern the impact of the French Revolution.
Of course, most of my `howto' files are not historical. They are how to install Hans Reiser's file system or how start a second X session.
So, there are good reasons to want software to scale, even when you start out with something small.
However, as Shirky points out, `situated software' is common. Indeed, most of my programming is `situated'. My introduction to programming is really an introduction to writing `situated software': as I say, it is
an elementary text for people who are not programmers.
As Shirky says... it's cheaper and faster to build, has fewer issues of scalability, and likelier uptake by its target users.
In the past I have focused on the individual: `how to customize and extend your working environment'.
Shirky focuses on groups: he explains this with an an anecdote, which is a good way to talk about a form that does not scale:
In a class... , which I taught last fall, the students worked in small groups to design and launch software to support some form of group interaction. To anchor the class, I required that whatever project they came up with be used by other[s].... The first order benefits ... were simple: the designers came from the same population as the users, and could thus treat their own instincts as valid ....
Yes, my introduction does the same: but in my case I was thinking more of the person writing for himself or herself than of the person writing for his or her peers. (One the problems I have noted with programmers is that they write for other programmers — their peers — that is one of the reasons user interfaces and documentation are bad. Only organizations that attend to `normal end users' create software that `normal end users' actually like.
Shirky goes on to say,
... I hadn't anticipated .. the second-order benefits. Time and again the groups came up against problems that they solved in part by taking advantage of social infrastructure or context-sensitive information ....
He gives an example,
One project, The Orderer ... was for coordinating group restaurant orders, common in late-night work sessions. The other, WeBe ... was a tool for coordinating group purchases of things like chips or motors. Because money was involved, a [regular] approach would require some way of dealing with the threat of non-payment, using things like pre-pay or escrow accounts, or formal reputation systems.
Instead, in both projects the students decided that since all the users were part of the [local] community, they would simply make it easy to track the deadbeats, with the threat of public broadcast of their names. The possibility of being shamed in front of the community became part of the application design, even though the community and the putative shame were outside the framework of the application itself.
As for the problems, Shirky points out,
[`Situated software'] 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 ...
Yes, indeed; `greater brittleness' is a nice way of saying `it fails when you scale'.
But Shirky ends with the interesting point that
... 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 tests of design quality or success, but which nevertheless function well, because they are so well situated in the community that uses them.
I think Shirky is right.
Return to: Notions
Or return to: Rattlesnake Home Page