malvasia bianca

The following bit from Brian Marick’s summary of boundary objects caught my eye:

Ivermectin is a popular drug for deworming animals. Onchocerciasis (river blindness) is a chronic illness that’s a particular burden in sub-Saharan Africa. Since river blindness is caused by a worm susceptible to ivermectin, the manufacturer (Merck) desired to donate ivermectin to fight the disease. That presented some problems. For example, it would not be in Merck’s interest if the bulk recipients responsible for redistributing ivermectin to people instead resold it into the lucrative veterinary market. On the other hand, it would also not be in Merck’s interest to tell the recipients (including national governments that are markets for other Merck drugs) that they are not competent or trustworthy enough to receive ivermectin. Merck needed organizational distance.

The solution was for Merck to donate the drug to a non-profit non-governmental organization. An independent expert committee would make the decision about which applicants (both governments and non-governmental organizations) would then receive the drug. This committee is a boundary object. To Merck, it provides distance: Merck donates the drug, reaps the benefits in good will and tax deductions, but is insulated from political repercussions. To the bulk recipients, the committee is the dispassionate judge of applications, end-point of an application process, and advisor during implementation.

This situation and its solution immediately reminded me of the notion that “All problems in computer science can be solved by another level of indirection.” But it’s not just that broad aphorism: the example reminds me of Bob Martin’s SOLID principles in particular. (The first five principles listed here; see also this Hanselminutes show on the topic.) I don’t think all his principles apply to the drug example, but more than one does.

The most obvious example is the Single Responsibility Principle. Merck is a big company that does lots of things; to handle this problem, they created a separate organization that has only one job, to deal with dispensing ivermectin.

I’ve squinted at the the Open Closed Principle a few times, and I can’t see how it applies to this situation – the types of modification that the OCP is talking about don’t seem so relevant here.

The Liskov Substitution Principle also doesn’t seem particularly relevant. It’s about base classes and derived classes; the only example of that that I see here is that you could think of the abstract concept of an applicant as a base class, with concrete applicants as derived classes, but that’s a pretty weak LSP situation: the base class is so abstract, the derived classes are so concrete.

Skipping ahead to D, the base and derived classes are a much better fit for the Dependency Inversion Principle. In fact, the second paragraph quoted above is all about that principle: rather than having the concrete company Merck deal with concrete recipients of donations of the drug, we introduce multiple abstractions. From Merck’s point of view, the NGO is something of an abstraction: as long as Merck knows enough about the NGO to trust that they’ll do a reasonable job dispensing the drug, it doesn’t have to worry about the details of the process. Similarly, from the applicants’ point of view, the NGO is a relatively abstract organization compared to Merck. (Or is it? Am I conflating this with the Single Responsibility Principle? Certainly there are fewer opportunities for linkages between the applicants and the NGO than between the applicants and Merck as a whole.) From the NGO’s point of view, the very notion of “applicant” is an abstraction placed on real people, real organizations.

Going back to I, the Interface Segregation Principle also seems relevant, though admittedly my justification for it here seems very similar to my justification to the Single Responsibility Principle: the NGO is exactly the interface to Merck for clients who want free ivermectin.

Does this analogy hold up in other examples of boundary objects? Can we relate the Open Closed Principle and the Liskov Substitution Principle to examples outside of programming? Can we run our analogy in the other direction, finding properties of boundary objects that suggest principles of good programming?