Consider the following two major questions:
Software reuse promises to aid in the production of reliable and cost efficient systems. As such, it should surely be part of a software curriculum. Even more important, perhaps, is the fact that a standardized and controlled method of studying reuse, similar to the study of expert work in the social sciences, can be a valuable tool in computer science education.
For the purpose of software education, software reuse should include reuse of code, specifications, and various types of documentation. In addition, students should be taught and encouraged to reference previously created systems and to create new software systems at least partially from previously developed components. This material should be able to be integrated into existing software engineering and computer science curriculum without major changes. In addition, the construction of previously developed components should be available for study, to aid in the development of techniques and talent.
As agreed elsewhere in the conference, as software systems grow in size and complexity there are increasing occurrences of cost overruns, time overruns, and system failures. Indeed, as more and more critical functions are controlled by software systems, the dangers of system failures are rather frightening.
Software reuse can aid system reliability in that integrated components will probably be better understood, crafted, and tested in the process of designing for reuse. There also can be considerable cost and time savings if components can be easily located and integrated. That could lead to greater reliability as well, because it is the time crunch that frequently causes developers to take short cuts in designing and testing. Of course, we do not think reuse is a software bullet, nor do we think that it can be achieved easily. We recognize the problems encountered, such as the cost of designing for reuse and the difficulties (technical, legal, social, etc.) in using components developed outside of an organization.
Designing for reuse as well as designing with reuse pose particular problems in academia. Teachers do not wish to put their efforts into learning a technology that is not yet mature and indeed that may not even be successful. Particularly in the field of computer science, there is so much new technology to learn daily that teachers must ration their time carefully. Methodologies and standardized taxonomies, templates, and metrics have not yet been developed. Appropriate textbooks and other course materials have not yet been produced. The allocation of course time in academia, via semesters of a few months, may not be appropriate for learning reuse material. And, of course, grading in academia has traditionally penalized students that ``reuse'' others' work. Unlike the social sciences, where students are expected to research good quality work (evaluated by experts and maintained in a library) and integrate this work into their own with appropriate footnotes, computer science courses usually have students write code ``from scratch.'' There are exceptions with C and FORTRAN libraries, for example, but the level of reuse is small and lightly documented.