Due to my position between industry and academia, over the past few years I’ve been reading a lot and writing a bit about the research-practice gap in computer science (CS). I’ve discovered that many of the issues about the research-practice gap in CS are not unique to our field. Other fields, such as medical or social sciences, have been facing similar problems. I believe we can learn a lot from them.
Recently, I came across an interesting article about the research-practice gap in health services. In the editorial "Research in general practice: who is calling the tune," Tom O’Dowd made the following claim:
"Often in health services research the questions are asked and answered by people outside general practice but using general practitioners as respondents or data gatherers. There is usually no involvement of the general practitioners in the analysis or discussion of the project, although their time is acknowledged. Surely this is a modern form of colonization at intellectual and professional levels." (British Journal of General Practice, October 1995, page 515)
After reading this editorial, I started to wonder if this claim would be true in my own field. So I did a simple exercise, and replaced "general practice" with "software engineering" in Tom O’Dowd's original text:
"Often in software engineering [or another CS field] research the questions are asked and answered by people outside software engineering practice but using software engineering practitioners as respondents or data gatherers. There is usually no involvement of the software engineering practitioners in the analysis or discussion of the project, although their time is acknowledged. Surely this is a modern form of colonization at intellectual and professional levels."
I am of the opinion that the adapted claim is true, at least partially. I have seen many research contributions about practice where I felt that involved practitioners could have been credited more or could have given an opportunity to contribute as co-authors. As a practitioner, I also have been approached a number of times to participate in research projects where my role was limited to anonymously filling in questionaries’ and interview forms. None of the times I was invited or given an opportunity to actively participate in analysis or discussions. The researchers had good intentions. But they were amateurs, usually students with little or no practical experience in domains they were studying.
My main reaction in mentioned situations was not the feeling of being "colonized." Rather, it is the feeling of wasted effort and missed opportunity. Doing research in practice is rare and difficult, but doing it naively creates more harm than good. At best, it does not help bridging the research-practice gap. At worst, it makes the gap wider, as practitioners may be reluctant to collaborate in any further activities.
I would definitely like to encourage academic researchers to connect to practice more. But academic researchers should be careful not to be perceived as "intellectual colonists." They should not treat practitioners as mere objects of their studies or simple sources of data. In my view, default mode of collaboration between researchers and practitioners should be a research partnership. Practitioners can provide invaluable real-world knowledge and experience. As noted by Fred Brooks, it is easy for academic researchers to overlook some crucial properties of real-world (The Design of Design, page 82). Practitioners, on the other hand, generally lack research skills. Academic researchers, therefore, can help creating the research climate in practice. They can supervise practitioners in doing research, and further expand or generalize initial research results and connect the results to existing body of knowledge.
I am happy to see that several venues are providing space for research-practice partnerships. The IEEE Software Insights column, for instance, publishes contributions from software engineering practitioners, offering them coaching and mentoring, informal reviews prior to submission, an official peer review, and professional editing support. The CACM Practice column and ACM Queue follow similar paths. But, in general, this type of collaboration is unusual, and not encouraged in academia.
Academic researchers are not the only ones to be blamed. Practitioners should not let themselves be "colonized." Practitioners are often uninterested in research and passive in interaction with researchers. To benefit from research projects and collaboration with academia, practitioners need to be more proactive. They need to propose research questions, do some research themselves, and proactively look for opportunities to create partnerships with academic researchers.
As a take-away message, I propose introducing the "anti-colonization test" for projects that involve collaboration between academic researchers and practitioners. This test requires repeating the same exercise I did in the beginning: taking Tom O’Dowd’s claim about general practice research and replacing the term "general practitioner" with "my own field practitioner." If the resulting claim even remotely looks as something that may be true, then the project has failed the test. It may a good moment to take a step back and rethink the proposed researcher-practitioner collaboration form.
eljko Obrenovi is principal consultant and head of Software Measurement and Analysis Group at Software Improvement Group, Amsterdam, The Netherlands.
Interesting read. I was working with a local software industry on code review tool. Publications were done, and prototype was also developed. But, still I had to do lot more work to make the tool industry-ready for testing, and this extra effort often did not turn into money or publications. So, this is the downside I found with collaboration. But yes, I experienced the gap myself, and now am trying to choose more practice-oriented research problems.
Displaying 1 comment