Adoption of Software Engineering Process Innovations: The Case of Object Orientation
Organizations increasingly rely on information technology (IT) both to perform their day-today operations and as a source of new products and services. The popular focus has been on hardware components, and that story has been overwhelmingly positive: the new technologies that come to market are cheaper, more reliable, and more portable than previous ones.
However, much less has been written about the software side of IT, and what has been written has not been positive. We commonly read that software is late, over budget, and of poor quality. Specific examples of software in the news are almost always negative — microcomputer software vendors that deliver releases late, federal government systems projects that never reach the implementation stage, and the recent telephone system outage that was blamed on a Texas supplier who “changed only three or four lines of the program.”1
This imbalance has reached such proportions that it has been termed the software crisis. Software production represents the single biggest obstacle to the successful use of IT in organizations; all precepts such as “using IT for strategic advantage,” “reengineering the business,” and “informating the workplace” become mere slogans if the necessary software is not properly delivered on time.
Into this void have rushed a multitude of vendors and consultants offering solutions to the crisis. A quick review of trade press magazines will reveal articles on such topics as computer-aided software engineering (CASE), rapid applications development, cleanroom software engineering, software factories, and object-oriented (OO) approaches. All of these represent software engineering process technologies, that is, means by which an application software product is created (hereafter “software process technologies”).2 The idea that process technologies in general are critical sources of economic success is gaining acceptance.3 However, the problem with this rich set of software process technologies is that they may be technically incompatible, or, if not, then at least sufficiently expensive and requiring significantly large changes in an organization’s operation that they are unlikely to be successfully adopted at the same time.
How, then, can the chief information officer (CIO) of a large business application development organization choose which, if any, of these new software process technologies to adopt? Unfortunately, the choice of a new approach is rendered very difficult by the lack of unbiased information sources. All of the technologies are shrouded in new vocabularies and explainable only by a self-selected cadre of experts.
References (36)
1. M.L. Carnevale, “DSC Says Software Change Led to Phone Outages,” Wall Street Journal, 10 July 1991, p. 5.
2. The innovation literature distinguishes process technology innovations from product innovations. A process innovation is one that changes the production process, that is, the way a product is produced. Most industrial tools, when first introduced, are simultaneously process and product innovations — a product innovation for the tool producer and a process innovation for the tool consumer. For example, for a DBMS vendor, a new RDB offering is a product innovation; for a systems developer, RDB technology is a process innovation that, among other things, involves the purchase of a product. As this article is targeted at consumers rather than producers of software technologies, we define them as process innovations. For further reading on the topic of process and product innovations, see: