Summary: Successful software engineering research
February 6, 2009
Summary of the article “Successful software engineering research”
Summary: Successful software engineering research
Parnas, D. L. (1998). Successful software engineering research. ACM SIGSOFT Software Engineering Notes, 23(3):64-68.
Parnas’ essay is a plea to computer science/software engineering researchers to be more relevant to practicing developers by doing research the way he does it — essentially, by doing design science research. He explicitly mentions the rigor/relevance dilemma (or failure in this case) as why he is so concerned: software engineering researchers write papers that are not useful to practitioners. In this case, it is in the first sense that Straub and Ang (2008) describe: that the choice of topics or themes that researchers tackle are not helpful to practitioners.
He was influenced heavily in his outlook on research by two things: his engineering colleagues and a particular experience in an industry setting early in his career. He describes engineering research as follows:
“The majority of those papers begin by describing a problem that is frequently encountered in connection with product design or production. They proceed to develop a model of the essential or fundamental parts of the problem, abstracting from facts that they consider irrelevant, and then proceed to analyse that model Finally, they show how the results of their analysis can be applied to solve, or improve the solution of, the original problem. Somewhere in the paper, there is a survey of alternative approaches, including those in the literature and those in use in other industrial environments” (p. 64)
This is very close to the seven necessary parts of a design science study proscribed by Hevner et. al. The only thing lacking from his descriptions are explicit rigor and scientific contribution, and (due to the nature of engineering as being about physical objects) deals with only mentions one of the four kinds of IT artifacts: models.
What is interesting about Parnas’ paper in contrast to Hevner is Parnas’ emphasis on close ties to the practitioner community, emphasizing personal interaction with actual developers to learn what real problems they encounter instead of considering software engineering from an academic distance. In a critical experience earlier in his career, Parnas was fortunate enough to be embedded in a company among developers and was able to observe them at close hand and inspect their code and other work products. This had profound impact on the way he chose problems to work on, and in the kinds of solutions he finds. It was from this experience that he developed the now commonly used (but then nearly unthinkable) idea of information hiding in software design.
He describes some promising areas for research which yet have very little activity: inspection methods (allowing code inspectors to “proceed systematically, carefully considering all cases in a way that provides confidence that nothing has been overlooked” (p. 66); and documentation (studying ways to make documentation not be “unclear, incomplete, inconsistent or inaccurate” (p. 66).
He ends by giving advice to researchers: keep close to practitioners — read their code; look for causes instead of symptoms; look for problems that are longer term/bigger problems, not ones that developers are likely to solve themselves; ask why practitioners don’t use the ideas from software engineering research; be wary of fads and buzzwords.
References
- Hevner, A., March, S., Park, J., and Ram, S. (2004). Design science in information systems research. MIS Quarterly, 28(1):75-105.
- Straub, D. W. and Ang, S. (2008). Readability and the relevance versus rigor debate. MIS Quarterly, 32(4):iii-xiii.
