Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick

191.8

⇒

167.2

⇒

186.2

183.6

184.0

183.2

184.6

Sat, 03 Apr 2004

Situated software

Clay Shirky has an important piece about what he calls situated software, "software designed in and for a particular social situation or context". Some representative quotes:

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. [...]

These projects all took the course's original dictum -- the application must be useful to the community -- and began to work with its corollary as well -- the community must be useful to the application. [...]

We constantly rely on the cognitive capabilities of individuals in software design -- we assume a user can associate the mouse with the cursor, or that icons will be informative. We rarely rely on the cognitive capabilities of groups, however, though we rely on those capabilities in the real world all the time. [...]

(Via Ralph Johnson on the uiuc-patterns mailing list.)

This makes me think of all the custom software that small development teams build around the product they're developing. They're a small social group. Can thinking in Shirkyesque terms help? Would it help them pay attention to things they overlook now?

Also: zillions of people are building support code for their small group, then putting it out into the world. Keeping Shirky in mind, what might they do differently? One thing that comes to mind is Michael Feathers' notion of stunting a framework. He suggests small frameworks that are intended to be owned and changed, not merely used by subclassing or plugging.

See also Ben Hyde's comments here and here:

Another point to make about situated software is this balance between a forgiving environment and a strong signal that helps the software to adapt.

The challenge in making a thing survive over time is getting it to adapt.

It's not the software alone that will adapt. From a manglish perspective, what's especially interesting is the possibility that the social situation that supports the software will change in response to it, which will change the software, which...

And more than that might change. Shirky talks about how software creators used the physical environment:

[...] take most of the interface off the PC's dislocated screen, and move it into a physical object in the lounge, the meeting place/dining room/foosball emporium in the center of the ITP floor. Scout and CoDeck each built kiosks in the lounge with physical interfaces in lieu of keyboard/mouse interaction.

(Information radiators, again.) As this goes on, will the lounge and the way people use it evolve?

So suppose we want to start paying more attention to how our secondary, "quick hack", project support work interacts with the micro-social, the micro-cultural, and the physical environment - and to how all those things evolve together. How do we do that? How do we notice gradual changes in the air we breathe? How does a project's network of support evolve in the steady sort of hill-climbing way that we hope the product itself evolves?

Hmm.. I sense an Agile Development Conference or XP Universe Open Space session coming on.

Coming down to earth... prior to attentiveness, there must be skill. Fortunately, Mike Clark's writing the book on that one.

## Posted at 10:54 in category /misc [permalink] [top]