This chapter is based on the article Research and practice: the curious case of ‘small’ researchers-practitioners, Communications of the ACM 56, 9 (September 2013), 38-40.
Astronaut Ronald E. Evans outside the Apollo 17 spacecraft. Wikimedia Commons
In recent years we have witnessed more attempts at bridging the practice-research gap in computer science . ACM and IEEE Computer Society , for example, seem to be increasingly more open to “the voice of practice.” Communications now includes the Practice section. ACM Queue promotes itself as an online magazine for practicing software engineers, “written by engineers for engineers.” ACM interactions describes its goal as to “lay between practice and research…making…research accessible to practitioners and making practitioners voices heard by researchers.” IEEE Software defines its mission as to build the community of leading software practitioners. The International Conference on Software Engineering (ICSE) has the Software Engineering in Practice track, and, similarly, the ACM SIGCHI conference accepts case studies intended to “specifically reach out to the practitioner communities.”
While the research-practice symbiosis seems to be flourishing, doing research as a practitioner is still not easy. It is even more difficult if research is not conducted in big companies or in collaboration with universities. Many of us are researchers-practitioners working in relatively small companies. By researchers-practitioners, I mean practitioners with clear practical tasks in their job, but who have background or skills of a researcher, obtained, for example by getting a Ph.D. or working as a postdoctoral researcher. And I call these practitioners “small” because they usually do research independently or in small teams, and cannot associate with their work research reputation and influence of their institution or companies. In small companies, we may not have a number of things that researchers in universities or big companies take for granted,  such as an explicit research department, bud-get for conferences, freedom, or even the job description and status of a researcher. But we can bring to practice the benefits of research approach, rigor, and discipline. And we can make accessible to the research community valuable insights and unique lessons from practice.
Contributions of small practitioners-researchers, however, are not always recognized and valued. Furthermore, they face a number of challenges and obstacles that researchers in big companies or in universities do not. In this Viewpoint, I want to call attention to the value of doing “small” research in small companies, and point out some of the main obstacles that such work faces.
Recognizing the Value of “Small” Research in “Small” Companies
Researchers are, in general, good in critical thinking, analysis, and dissemination of their findings. These skills, combined with practical work, can bring to their companies and the research community several benefits. Here, I discuss two characteristics of research work I find particularly relevant for small researchers: generalization and publishing.
Generalization. Normally, the goal of practice is to create a successful product, and lessons learned in this activity are restricted to the particular solution and the people involved in it. To be acceptable as research contributions, however, these lessons need to be generalized, applicable beyond original context, and useful to others (see the chapter Design-Based Research for more details about such generalized knowledge).
Generalization is not only an abstract academic goal, but it can be valuable for practice. In my previous position, I worked in a relatively small company in a department called “best practices.” The primary goal of our department (one engineer, one architect, and one researcher) was to collect, generalize, and share best software development practices related to our software products. Being a relatively small company meant we did not have the luxury to repeat errors, and our department was built with the aim of maximally leveraging the lessons learned in our projects. Our task was not to simply collect these lessons, but to generalize them and make them usable and understandable to the broader audience, within and outside our company. Applying research approaches, such as using analytic generalizations, evaluations, and connecting our findings to existing work, helps significantly. Good generalizations can also help avoiding low-level technical jargon. Consequently, our work has been valuable not only for our architects and developers but also to our sales team, who were able to use some of our analyses as arguments in discussion with demanding and critical clients. In contrast to research in big companies, small researchers are closer to the “battlefield” and can more directly contribute to the company’s success.
For the research community, generalizations of practical solutions on a broader scale and across multiple projects are particularly valuable. For example, we recently published an article about security patterns of integrating authentication and personalization, generalizing security implementations in several of our projects . I also see a potential value of having more smaller companies sharing their “best practices,” combined with additional effort of the academic community to connect and further generalize these practices. I had an opportunity to witness the value of this approach firsthand, when I was one of the guest editors for the special issue of ACM Multimedia Systems Journal on Canonical Processes of Media Production . This special issue was not only a collection of articles, but it presented a model of media production that was based on generalization of 10 companion articles describing different media production domains (each of which presented some specific media production system or project). Contributions included several media production companies, artists, and academic researchers. The resulting model significantly benefited from interaction and generalization of issues from our industrial contributors. Our industrial contributors also benefited from connecting their work to other solutions, as they were able to get new ideas and see that their issues are shared by others and that they can learn from each other’s experiences. It would be interesting to see more such attempts in other domains, where small researchers would present their initial generalizations of their domains, and a broader research community would connect these generalizations to other industrial and academic work.
Publishing Results. Publishing findings from practice has obvious benefits for the research community as it enables it to obtain deeper insights about relevant practical issues, and gets more realistic overview of the state of the practice . Stolterman, for example, argued that many research projects about theoretical approaches, methods, tools, and techniques for supporting interaction designers in their practice failed because they were not guided by a sufficient understanding of the nature of practice .
Publishing can also significantly help a small company. One of the most important values of publishing in peer-reviewed venues is receiving knowledgeable and valuable criticism. By publishing your results, you also have to make the reasoning behind your generalized claims explicit, public, and open to critical reflection and discussion, which enables receiving feedback of experts and colleagues from different communities. Publishing results can also have positive influence on company’s promotion and hiring of new employees. Small companies normally cannot sponsor huge events, but presenting a paper at a conference, combined with promotion of this event by the company, may give a company a fair share of visibility and promotion for much smaller price. Small companies may also have more difficulties attracting high-quality employees, and I received unexpected encouragement to actively participate in conferences from the Human Resources (HR) department. The HR department elaborated that such activities can help the company to demonstrate the quality of its work and its people, both to potential new clients and employees.
Doing research outside universities or big companies, even when conducted with rigor and discipline, comes with a number of challenges. Finding time and resources for research in small companies is always challenging. And practice does not always recognize the value of research contributions. It may require significant time and effort to convince relevant people in your company of the potential value of doing research. Practice also needs to understand that it is not enough to simply relabel “development” as “research,” and that research cannot be done properly without individuals who are disciplined and objective enough to conduct it with scientific rigor.
Less obviously, and contrary to the recent trend of openness for “the voice of practice,” a small researcher-practitioner may face even bigger barriers from the research community. Research work is difficult and incomplete if a researcher is not a part of a community of researchers. However, for researchers-practitioners coming from smaller or less-known companies, it may be difficult to become a part of such a community. First, it may be difficult to find a venue open for contributions of the practitioners. Reviewers also may be biased toward more academic contributions and methods. When you try to submit some of your work for publication in places that seem to promote strong practice orientation, you may find many of them are not open for your contributions. For example, the Communications Practice section publishes articles “by invitation only.” Similarly, ACM Queue reviews articles only from authors who have been “specifically invited to submit manuscripts.” This makes it practically impossible for people outside a relatively small group of elite practitioners to even try to contribute regardless of the quality of their contribution.
Another barrier from the academic side comes from stereotypes about the research process. When working for my previous company, I tried to join the ResearchGate, as several of my papers have been uploaded there by other co-authors. However, when trying to register with my company email address, I received the following email message: “We’ve reviewed your request and regret to inform you that we cannot approve your ResearchGate account at present. As ResearchGate is a network intended for scientific and academic exchange, we ask that you sign up with an email address affiliated with your institution (e.g., university, organization, or company) or provide us with details of your independent research (e.g., research discipline and current project).”
My email address was affiliated with my institution (a company), in an obvious way (my name at my company domain). However, it seems a company is considered a research organization only if it is a well-known institution, and with a separate research department (for example, Google Labs, Microsoft Research, Yahoo Research, Philips Research…). This anecdote points to a problem of researchers from smaller companies who may be discriminated in their attempts to become part of the research community, and may have difficulties passing the threshold of being considered worthy of belonging to the research community. Also the notion of a research project seems to be closer to the academic environment where researchers work for several years on the same project. In practice, there may be a long-term research thread, but research contributions do not necessarily belong to an explicit project.
There is a potential value for both, practice and research, if we have more active “small” researchers-practitioners. With declining numbers of research positions in academia  we have increasing numbers of research-capable people entering small companies. Practice is rich and still hugely unexplored area, and researchers-practitioners may be in unique positions to witness or make important discoveries in many areas of computing. However, there are a number of barriers and challenges that “small” practitioners-researchers face. Practice needs to become more aware about the value of applying research rigor and discipline, and the research community must be more open for attempts of “small” researcher-practitioners to join them as equals. Educational institutions also need to think about how to educate researchers-practitioners, rather than researchers or practitioners. It also requires more continued efforts of small researchers-practitioners to do high-quality research, contribute to the research community, and call attention to their problems.
Bourne, S. and Cantrill, B. Communications and the practitioner. Commun. ACM 52, 8 (Aug. 2009), 5.
Briand, L. Embracing the engineering side of software engineering. IEEE Software 29, 4 (July–Aug. 2012), 96–96.
Glass, R.L. One man’s quest for the state of software engineering’s practice. Commun. ACM 50, 5 (May 2007), 21–23.
Hardman L., Obrenovic, Z., and Nack, F., guest eds. Special issue of ACM Multimedia Systems Journal on canonical processes of media production 14, 6 (Dec. 2008), 327–433.
Norman, D.A. The research-practice gap: The need for translational developers. interactions 17, 4 (July 2010), 9–12.
Obrenović, Ž. and den Haak, B. Integrating end-user customization and authentication: The identity crisis. IEEE Security and Privacy 10, 5 (Sept./Oct. 2012), 82–85.
Spector A., Norvig, P., and Petrov, S. Google’s hybrid approach to research. Commun. ACM 55, 7 (July 2012), 34–37.
Stolterman E. The nature of design practice and implications for interaction design research. International Journal of Design (IJDesign) 2, 1 (2008).