malvasia bianca

The original paper on boundary objects gives a partial taxonomy of boundary objects; given my earlier thought experiment, I thought I’d see if I could find programming analogues to any parts of their classification.

Star and Griesemer’s first type of boundary objects are Repositories:

These are ordered ‘piles’ of objects which are indexed in a standardized fashion. Repositories are built to deal with problems of heterogeneity caused by differences in unit of analysis. An example of a repository is a library or museum. It has the advantage of modularity. People from different worlds can use or borrow from the ‘pile’ for their own purposes without having directly to negotiate differences in purpose.

At first, I thought this type was kind of banal, corresponding perhaps to collection objects in software, but now I think it’s more interesting than that. Reading their description more closely, I don’t get a collection object vibe: collections in the programs that I write usually contain a quite uniform group of objects, and those objects are used for one or two specific purposes; the above, however, emphasizes heterogeneity and differences in purpose.

That last sentence, in particular, reminds me of mashups; if you combine that with standardized indexing, I’m getting a very strong RESTful vibe from this. In a RESTful application, names are key but internal structure can vary from location to location, and outsiders can use standard tools to access the data that the application exposes and borrow it for their ends.

Next in their taxonomy is the Ideal Type:

This is an object such as a diagram, atlas or other description which in fact does not accurately describe the details of any one locality or thing. It is abstracted from all domains, and may be fairly vague. However, it is adaptable to a local site precisely because it is fairly vague; it serves as a means of communicating and cooperating symbolically—a ‘good enough’ road map for all parties. An example of an ideal type is the species. This is a concept which in fact described no specimen, which incorporated both concrete and theoretical data and which served as a means of communicating across both worlds. Ideal types arise with differences in degree of abstraction. They result in the deletion of local contingencies from the common object and have the advantage of adaptability.

My first reaction here was to try to make an analogy with abstract types; indeed, they use the word “abstracted” in their second sentence, and I can easily see their species example being used as an example in an OO textbook. The only thing that gives me some amount of pause when proposing this analogy is their use of it as a talisman communication tool between multiple parties, many of which may turn out to want to know more about the details of the objects in question.

In contrast, in my programming experience, if I have a concrete subclass of an abstract class, it’s more typical for almost all users to only care about the abstraction, while perhaps only one user cares about the concrete class. Though, rereading what they say, maybe their species example suggests that the correct analogy to the Ideal Type is to (any sort of) class, with the non-ideal objects being instances, rather than subclasses? Either way, though, I get the feel that I’m missing something in the way that I was missing something with my earlier analogy between a Repository and a collection: is there another analogy waiting to be found here that’s a bit grubbier in the way that the RESTful example is?

Third up are Coincident Boundaries:

These are common objects which have the same boundaries but different internal contents. They arise in the presence of different means of aggregating data and when work is distributed over a large-scale geographic area. The result is that work in different sites and with different perspectives can be conducted autonomously while cooperating parties share a common referent. The advantage is the resolution of different goals. An example of coincident boundaries is the creation of the state of California itself as a boundary object for workers at the museum. The maps of California created by the amateur collectors and the conservationists resembled traditional roadmaps familiar to us all, and emphasized campsites, trails and places to collect. The maps created by the professional biologists, however, shared the same outline of the state (with the same geo-political boundaries), but were filled in with a highly abstract, ecologically-based series of shaded areas representing ‘life zones’, an ecological concept.

This one was hard for me to grapple with. (And I’m not the only one; that link, incidentally, gives references to extensions of this taxonomy.) Even in the physical world, it’s a bit hard for me to tell examples of this: is the concept really restricted to large-scale geographic areas? That seems a bit limiting.

The paper in question discusses the Museum of Vertebrate Zoology at the University of California, Berkeley; is it a boundary object? I tend to think so: quoting from the definition on page 393,

This is an analytic concept of those scientific objects which both inhabit several intersecting social worlds (see the list of examples in the previous section) and satisfy the informational requirements of each of them. Boundary objects are objects which are both plastic enough to adapt to local needs and the constraints of the several parties employing them, yet robust enough to maintain a common identity across sites. They are weakly structured in common use, and become strongly structured in individual-site use. These objects may be abstract or concrete. They have different meanings in different social worlds but their structure is common enough to more than one world to make them recognizable, a means of translation.

And certainly the MVZ is robust enough to maintain a common identity, but it means something different to a postdoc working there, to somebody who has spent her career there, to a visiting researcher, to a university administrator, to an outside funder, to a janitor. (Indeed, much of the paper is devoted to showing such differences in meanings.) Given that, I would treat the MVZ as a Coincident Boundary: though not spread over a large-scale geographic area, it’s still a place which means different but related things to different people.

Which, to be honest, doesn’t help me directly with finding programming analogies; maybe a function body in the input to a compiler that means different things to the lexer, the parser, the optimizers, the code generator, the debug info generator? Actually, I think maybe the more important analogy is a bit more conceptual and not internal to programming: maybe we could think of a domain object as an example of a Coincident Boundary that means one thing to a programmer, another thing to a database administrator, a third thing to an system architect, a fourth thing to an XP Customer, a fifth thing to a marketer, a sixth thing to an end user. I’m not completely sold on that, but I do think that domain objects are boundary objects of some sort, and they’re a better fit to Coincident Boundaries than anything else in Star and Griesemer’s taxonomy.

The last entry in their taxonomy is Standardized Forms:

These are boundary objects devised as methods of common communication across dispersed work groups. Because the natural history work took place at highly distributed sites by a number of different people, standardized methods were essential, as discussed above. In the case of the amateur collectors, they were provided with a form to fill out when they obtained an animal, standardized in the information it collected. The results of this type of boundary object are standardized indexes and what Latour would call ‘immutable mobiles’ (objects which can be transported over a long distance and convey unchanging information). The advantages of such objects are that local uncertainties (for instance, in the collecting of animal species) are deleted.

Class interfaces (whether concrete or abstract) are examples here, as are generalizations such as duck types or the sorts of dependencies that C++ templates impose on their parameter types. For example, templates don’t care about the details of an iterator as long as it exposes its increment operator under the name ++, its equality operator under the name ==, and so forth.

Network protocols are another example: indeed, what is better than TCP/IP at ensuring that data “can be transported over a long distance and convey unchanging information”? Stick it on the wire in a Standardized Form, and it will come back out the other end. We can use our RESTful example from above in this context as well: if you want disparate clients to all be able to talk to each other, it helps a lot if everybody speaks in terms of GET, POST, PUT, and DELETE.

And, as we did with the last example of the taxonomy, we can step away from the code a bit. An acceptance test is a Standardized Form: if the Customer and the engineers want to agree on what it means to complete that task, it sure helps if they can point to a Standardized Form for specifying that completion, and an acceptance test that both sides can read (and run!) is an excellent form for that agreement to take, for deleting uncertainties.

Interesting stuff. I’m curious what other classes of boundary objects people have come up with, and I should probably spend more time thinking about examples outside of the strict domain of code. And I really like the lens it gives on the messiness, the grunge, the lack of sterility of the RESTful approach: if you pin down enough so that people can talk to each other while leaving enough of the details undetermined so that different groups can use the entity in question for significantly different ends, unexpected synergies can flourish.