Adopting Software Engineering Research: A Consumer Problem or a Producer Problem?

By David Notkin

But why does this complaint arise so frequently? A couple of reasons are commonly given. One: it just takes a long time for technology to transfer from research into industry. Although I'm not an expert in the history of technology transfer, there is undoubtedly some truth to this observation. Two: we, as researchers, don't do a good enough job of educating industries (nor students), and that is where the failure rests. Again, there is surely some truth to this belief. But even when taken together, these reasons doesn't explain the whole problem. I think there is a third reason that dominates the first two: the difficulty in having industry adopt software engineering research is at its heart a producer problem, not a consumer problem. That is, we're generally not providing research that has content and form that meets the needs of practitioners. In some cases, the research doesn't solve problems that the practitioners face. In other cases, the research doesn't take into account constraints such as computing platforms, existing software engineering tools and processes, economic pressures, etc.

Let me use this observation to point out a philosophical issue that I have started to see much more clearly lately. Software engineering researchers generally have one of two philosophies. One philosophy is to figure out what would be great ways to engineer software and to try to convince practitioners to do it that way. Another philosophy is to figure out what practitioners are actually doing and to try to enhance their abilities to engineer software. If you will, the first philosophy is one of revolution, and the second is one of evolution.

There is a key belief system at stake here: does one believe, on the whole, that software is being built pretty well by pretty good people using pretty good tools and technologies? Not that there isn't room for improvement, and not that there aren't situations (perhaps safety-critical software) in which we need to slow down the demand until we can achieve satisfactory quality, but that we're doing OK. If you don't believe that, you probably adhere to the revolutionary philosophy camp. And that's going to make it pretty hard to convince those very same people that you have research that is going to help them turn the corner. (If you do in fact convince a number of people, you may well be off to the races. If, indeed, your ideas do hold merit when put into practice.)

If you do believe that things are basically OK, then you're more in the evolutionary camp. Now the question is, how do we help pretty good people engineer even better software (at lower cost, with better quality, and so forth)? With some luck and some experience, this attitude can lead to research questions that, when answered, have a decent chance of being tried and, if successful, put into practice. I live in Seattle, and we are often thought to have gray skies a lot of the time. But so far in this essay I'm sounding (even to myself) extremely black-and-white. And the reason is simple. I don't think that there is one "best" philosophy towards software engineering research. Indeed, we need a broad mix, because the discipline itself is so rich and complex. But we cannot afford to have a mixed attitude towards the practitioners in our field. If you fundamentally believe that software engineers (not software engineering researchers) are not especially smart, are not especially capable, are not especially knowledgeable, and are not especially educable, then you're not likely to be able to improve their plight. And to the degree that researchers hold this opinion--even if it is never stated, but is held deep in the heart--it is a certainty that their research won't be adopted, and it won't be the fault of the consumers. On the other hand, if one treats software practitioners with respect for their abilities and their knowledge, with sympathy and empathy for their problems, then one is far better positioned to improve the world of software engineering.

I fully anticipate that this essay will be misinterpreted in a couple of ways, so let me try to answer a few questions right now. First, this doesn't apply by any means to all software engineering research; we are a strong field that needs to become even stronger. Second, it is not and should not be the job of researchers to immediately address and try to solve all pressing problems of industry; we are still interested in general solutions to problems rather than specific instances (although one can learn an enormous amount from specific instances). This misinterpretation arises constantly, albeit implicitly, from some parts of the practitioner world, often when criticizing ICSE and other conferences with a research component; it is as unacceptable as having researchers who don't respect practitioners.

ICSE provides an opportunity for practitioners and researchers in software engineering to exchange ideas, problems, solutions, and experiences. Let's consciously use it to improve the discipline, especially by working hard--researchers and practitioners alike--to better understand each other's role and to respect each other's knowledge, intelligence, and abilities.