As a researcher who works on technology-enabled human learning, I am often talking with people who are interested in research but who are not researchers. Some are funders, as we are blessed in education with a growing number of philanthropic funders who want to invest in promising technology approaches to difficult educational challenges. Others may be at companies or in the service side of educational improvement. Surprisingly, one of the phrases they find most puzzling is "research and development." What is it?
This phrase is puzzling because people may see "research" in terms of activities, such as analyzing data, instead of goals. Is it "research" occurring anytime someone examines data? Conversely, they may see "development" entirely in terms of its output. Is it "development" anytime someone builds a new tool? In response, I’ve found it useful to talk about R&d, r&D, R&D, and r&d, as elaborated below.
Although Research uses specific skills (like collecting data and analyzing it), so do other empirical activities. Not every activity that collects and uses data is a research activity. Research is different because it seeks to produce generalized knowledge.
Likewise Development (in an R&D sense) uses specific skills (like building prototypes, collecting feedback, agile cycles of improvement), and so do other activities. Development often aims to produce generalized functionality.
R&d often occurs when you build something just enough so you can use it to gather data to answer a research question and produce knowledge. The "d" part is often a prototype or tool that may not be ready for prime time, but it exercises the key functionality so researchers can study some question of broad interest and produce insights that can be applied beyond the tested tool.
r&D often occurs when a development project (wants to produce generalized functionality) wants to gather and use evidence for improvement—and thus draws on research skills. There may be user experience testing, for example. Or defining metrics and testing performance. Yes, there's an empirical component in the cycles of development work, but sometimes there is no effort to organize "what we learned" so that other people creating a different tool can benefit from the knowledge. The output is an evidence-based, generalized new functionality.
R&D where both generalized knowledge and generalized functionality receive balanced attention is pretty rare. Conducting R&D takes a lot of thought about management structure, levels of funding, kinds of expertise and talent, and how different types of goals can be met on a roadmap over time. The early days of the Internet strike me as R&D, because today we still use two kinds of results. We today still use both the protocols and technologies that were developed, but also the fundamental concepts that Internet pioneers articulated and argued for. There are many currently active examples of balancing R&D as well, but in this short blog, I don’t want to play favorites. I do greatly admire R&D teams that can organize their work to contribute doubly, through knowledge and through functionalities.
Finally, it bears mentioning that the world is full of r&d and this is a good thing. There is nothing wrong or lesser with r&d, as we all value well-executed products and apps that make our work easier. The process of producing such products often involves some research skills (even if no generalized knowledge is produced) and software development skills (even if the functionality isn’t novel or general, but simply executed very well). We all should value the use of these skills wherever they may make things better.
Jeremy Roschelle is Executive Director of Learning Sciences Research at Digital Promise and a Fellow of the International Society of the Learning Sciences.