"Systematic" versus "accidental" reuse in Japanese software factories

A major topic in software engineering is how to reuse or recycle product components across more than one system or project, making it unnecessary to keep specifying, building, and testing new products completely from scratch. While reuse may seem to be primarily a technological problem, this article illustrates how reusability also needs to be seen as a managerial and organizational problem. This is because the recycling of specifications, detailed designs, and actual code, as well as development tools, engineering methods, and test cases, can either be systematic -occurring as frequently as possible due to management planning as well as provision of s pport technologies and incentives -or accidental -occurring infrequently and in an ad hoc manner due to the lack of formal planning, support, or personnel incentives. The focus of the discussion is on techniques and tools used in Japanese software factories, especially Toshiba, which in the mid-1980s was routinely delivering software systems with nearly 50% reused code. INTRODUCTION A topic in software engineering as well as in product development management in general has continued to arouse interest among academics and practitioners: how to reuse or recycle product components across more than one system or project, making it unnecessary to keep specifying, building, and testing new products completely from scratch. ' The real problem is how build, deposit, and then find existing components so that reuse does not cost more than making new components, and final products with a lot of reused designs or code do not contain too many compromises in performance. Reuse may thus seem to be primarily a technological problem, depending, for example, on the structure of specific software components and their suitability for different application contexts, user requirements, or hardware platforms. This article, however, draws on examples from Japan to demonstrate that, in software as in other engineering domains, reusability also needs to be seen as a managerial and organizational problem. This is because the recycling of specifications, detailed designs, and actual code, as well as development tools, engineering methods, and test cases, can either be systematic -occurring as frequently as possible due to management planning as well as provision of support technologies and incentives -or accidental -occurring infrequently and in an ad hoc manner due to the lack of formal planning, support, or personnel incentives. Of course, if every product that a development group tries to build is totally different, then reuse is either impossible or limited to elementary process knowledge, such as general project-management expertise, or very common subroutines, such as screen handlers or date-conversion modules. For a series of projects where reuse is possible, however, many firms still find that reuse does not occur to the same extent as there exist opportunities based on redundancies in customer requirements and program functions. Because of the potential benefits to productivity and quality from reusing proven components, how to raise reusability to both technological and managerial or organizational limits has become a major strategic concern for software producers. This is especially true in Japan, where there persists a small number of available software packages, severe shortages of skilled programmers, and large demand for labor-intensive custom software (including programs embedded in hardware) where many of the required functions are not unique to each project. REUSE CONCEPTS AND TECHNICAL SUPPORT Reusable Components: Just as reuse of experience embodied in methods and tools is a common engineering and manufacturing practice, reuse of software components has its analog in any conventional industry where engineers design standardized, interchangeable parts that factories mass produce and then use in identical or even somewhat different end products. The notion of recycling pieces of software first occurred to programmers in the 1950s who found they did not have to keep rewriting common subroutines, such as for converting temperatures or sorting different types of data. By the mid-1960s, packages of reusable Fortran routines were commercially available from IBM. The idea of making and using reusable components gained further popularity during the 1968 NATO conference on software engineering when M.D. Mcllroy of AT&T suggested that governments and companies establish "components factories" to create mass-producible modules to serve as "black boxes" for new programs. Producers would benefit by building new programs from existing components that represented efficient designs, while users would have products that, even though containing some standardized parts, were tailored to their needs.2 Although Mcllroy referred primarily to reusable subroutines at the code level, reuse has gradually come to include data types, architectures, designs, whole programs, modules, and other elements (such as tools, methods, and experience), in addition to executable code, which often proved most difficult to reuse across different