What software engineering taught me about collaborative research
Encapsulation is one of these truly pervasive ideas in software design and engineering. We build software systems by separating out independent bits, building them separately and with welldefined ways of communicating between them. This makes it so that the module that talks to the database will not have to know any details of how to draw things on the screen. It also ensures that Amazon will not need access to Twitter’s databases for them to let met tweet my newest book purchases.
These communications between modules are often specified as APIs: specifications of the kinds of services a module can perform for others, and the kinds of data the module needs to see to do its work. A service, or a library, publishes an API — explains how to request work from it: what functions calls to request, what formats for input and output data. Software engineering and design spends quite some time on connecting modules along these sorts of specifications.
API as a metaphor for research collaboration
I have done some interdisciplinary research already, for instance my contribution to color semantics in linguistics. I am also active in a field that specifically looks for interdisciplinary collaborations, and where we spend some time discussing and working on interdisciplinary compatibility.
Among the things I learned when collaborating is that while I have expertise that can contribute, efficient collaboration requires me to adopt some of this encapsulation thinking. For anyone to be interested in using the techniques I know, they have to figure out how my techniques can fit with their research — what problems I could possibly solve for them, what information I could possibly produce for them.
I need, in essence, to publish an API to my expertise, a way to communicate my capabilities and my preferred (or possible) input and output formats. Really efficient collaboration also requires my collaborators to do some of this work themselves: it will be difficult to build a good collaboration if I need to be a cutting edge researcher in the application field as well before I understand their questions. Especially since I collaborate with different fields all the time, it ends up impossible for me to contribute if I have to assimilate the entire collaboration field before helping.
Basically, collaborative research ends up by force being an interactive process, where all collaborators contribute, all collaborators adapt their representations of their problems and knowledge to facilitate communication with their research partners.
So what?
On one level, this is a metaphor that helps me. I can think about the structures of my collaborative projects better with this metaphor. I have an easier time thinking about what I need to do to be an efficient collaborator when I phrase it as a software engineering problem.
This highlights, to me, the ways that collaboration and popularization have always seemed familiar. Being able to accurately and understandably explain what you are doing to the general public ties in with similar requirements as does being able to accurately and understandably explain what you are doing to a chemist, or a linguist, or a roboticist. There are shortcuts you can take when you know that your audience has a basic scientific education, but the two tasks still resonate.
It also highlights to me just why it is a difficult task to excel at. Being a good collaborator draws on some of the skills and procedures of designing and documenting a good API. And I know that API design and documentation is hard, and that badly designed and badly documented APIs are annoying and difficult to work with.
Next, I will start looking for interesting sources to read on API design, to see if I can extract any interesting principles from them to apply to collaboration and popularization of my scientific work.
