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]

About Brian Marick
I consult mainly on Agile software development, with a special focus on how testing fits in.

Contact me here: marick@exampler.com.




Agile Testing Directions
Tests and examples
Technology-facing programmer support
Business-facing team support
Business-facing product critiques
Technology-facing product critiques
Testers on agile projects

Permalink to this list


Working your way out of the automated GUI testing tarpit
  1. Three ways of writing the same test
  2. A test should deduce its setup path
  3. Convert the suite one failure at a time
  4. You should be able to get to any page in one step
  5. Extract fast tests about single pages
  6. Link checking without clicking on links
  7. Workflow tests remain GUI tests
Permalink to this list


Design-Driven Test-Driven Design
Creating a test
Making it (barely) run
Views and presenters appear
Hooking up the real GUI


Popular Articles
A roadmap for testing on an agile project: When consulting on testing in Agile projects, I like to call this plan "what I'm biased toward."

Tacit knowledge: Experts often have no theory of their work. They simply perform skillfully.

Process and personality: Every article on methodology implicitly begins "Let's talk about me."


Related Weblogs

Wayne Allen
James Bach
Laurent Bossavit
William Caputo
Mike Clark
Rachel Davies
Esther Derby
Michael Feathers
Developer Testing
Chad Fowler
Martin Fowler
Alan Francis
Elisabeth Hendrickson
Grig Gheorghiu
Andy Hunt
Ben Hyde
Ron Jeffries
Jonathan Kohl
Dave Liebreich
Jeff Patton
Bret Pettichord
Hiring Johanna Rothman
Managing Johanna Rothman
Kevin Rutherford
Christian Sepulveda
James Shore
Jeff Sutherland
Pragmatic Dave Thomas
Glenn Vanderburg
Greg Vaughn
Eugene Wallingford
Jim Weirich


Where to Find Me

Software Practice Advancement


All of 2006
All of 2005
All of 2004
All of 2003



Agile Alliance Logo