Software Processes Are Software Too, Revisited: An Invited Talk on the Most Influential Paper of ICSE 9

The ICSE 9 paper, “Software Processes are Software Too”’ suggests that software processes are themselves a form of software and that there are considerable benefits that will derive from basing a discipline of software process development on the more traditional discipline of application software development. This paper attempts to clarify some misconceptions about this original ICSE 9 suggestion and summarizes some research carried out over the past ten years that seems to confirm the original suggestion. The paper then goes on to map out some future research directions that seem indicated. The paper closes with some ruminations about the significance of the controversy that has continued to surround this work. Introduction “Software Processes are Software Too.” How many times I have heard that phrase quoted back to me in the past ten years! And how many times it has been (sometimes amusingly) misquoted too. Often I have been flattered to have had the ICSES paper [15] and its catchy title referred to as being “classic” and “seminal”. But often I have also been asked, “what does that really mean?” The idea is, alas, still misunderstood and misconstrued in some quarters. But amazingly, and gratifyingly, the phrase is still used, and the discussion of the idea still continues, even after ten years. The suggestion that software, and the processes that deal with it, might somehow be conceptually similar remains a powerfully appealing one that seems to have *This work was supported in part by the Air Force Materiel Command, Rome Laboratory, and the Defense Advanced Research Projects Agency under Contract F3060294-C0137. permission to &ke digitafiard copies of all or part ofthis mate&l for perSonal or classroom use is granted without fee provided that the copies we not made or distributed for profit or commercial advantage, the copy@bt notice, the title ofthe publication and its date appear, and notice is &‘a that copyright is by permission oftbe ACM, Inc. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires specific permission and/or fee ICSE 97 Boston MA USA Copyright 1997 ACM 0-89791-914-9/97/05 ..$3.50 led to a considerable body of investigation, The suggestion was immediately controversial, and continues to be argued. Subsequently I discuss why I believe this discussion indicates a pattern of behavior typical of traditional scientific inquiry, and therefore seems to me to do credit to the software engineering community. But what of the (in)famous assertion itself? What does it really mean, and is it really valid? The assertion grew out of ruminations about the importance of orderly and systematic processes as the basis for assuring the quality of products and improving productivity in developing them. Applying the discipline of orderly process to software was not original with me. Lehman [13] and other8 [18] had suggested this long before. But I was troubled because I had started to see the development of a whole new discipline and technology around the idea of software process, and to notice the emergence of many notions and tools that seemed eerily familiar. I was starting to see the creation of a software process universe parallel to the universe of notions and tools surrounding application software development. The more I looked, the more similarities I saw. Processes and applications are both executed, they both address requirements that need to be understood, both benefit from being modelled by a variety of sorts of models, both must evolve guided by measurement, and so forth. Thus it seemed important to suggest that software process technology might not need to be invented from scratch (or reinvented), but that much of it might be borrowed from application software technology. I have often been reminded that application software technology is still badly underdeveloped and that using it as a model for software process technology might be of dubious value. This, however, overlooks clear evidence that, while we have not mastered application software technology, we have, nevertheless, created a powerful assortment of tools, principles, and techniques in this domain. Thus, there is much to be gained from using obvious parallels to hasten the maturation of software process technology. It seemed important to suggest that the community should look to the more traditional and better-developed disciplines of application development to see what might be borrowed or adapted. It seemed clear that there were strong similarities, but likely that there were differences as well. Investigation of the extent of each seemed to be in order. The ICSE 9 talk invited community investigation of how processes and application software are the same and how they differ, so that relevant findings, approaches, and tools of one could be of use to the other. It has been gratifying to see that this invitation has been taken up and that these explorations are still ongoing. Conversely it has been disappointing to see the way in which the suggestion has continued to be misconstrued in some quarters. Subsequent sections will deal with these misconceptions in more detail, but the following brief summary seems in order here. Software is not simply code. Neither are software processes. Application software generally contains code. This suggests that software processes might also contain code. Coding software processes thus seems to be an interesting possibility. Research has borne this out. Programming is not the same as coding, it entails the many diverse steps of software development. Software process programming should, likewise, not simply be coding, but seemed to entail the many non-coding steps usually associated with application development. Process modelling, testing, and evolution research seems to have borne that out. There are many examples of application code that are not inordinately prescriptive, authoritarian, or intolerable to humans (eg. operating systems). Thus, there should be no presumption that process code must be overly prescriptive, authoritarian, or intolerable either. Process programs need not treat humans like robotsunless that is the intention of the process programmer. Process modellmg and coding languages demonstrate this. Finally, good software code is written at all levels of detail. Code contains fine scale details, but they emerge at lower levels, after high level code addresses larger issues. Similarly process code contains details that are nested below higher abstract levels. Process code, like application code, can demonstrate that precise implementation of broader notions in terms of lower level engineering details. Contemporary process coding languages demonstrate this too. The following section summarizes some research that suggests continued and broadened research into these issues. Parallels Between Software Processes and Appli-