Why Technology Transfer Is Needed

The software engineering field already has good practices for project planning and management, requirements engineering, design, construction, quality assurance, and process improvement. The problem is that too few practitioners know about the practices, and even fewer people use them. Table 21-1 lists some examples of best practices with which leading software organizations have accumulated a great deal of experience, that are usually successful, and that as far as I can tell from my consulting experience and various published industry reports are used by only a slim minority of software organizations.

Table 21-1. Software best practices that are rarely used^[2]

BEST PRACTICES	YEAR FIRST DESCRIBED IN PRINT OR FIRST COMMERCIALLY AVAILABLE
Project planning and management practices
Automated estimation tools	1973[3]
Evolutionary delivery	1988[4]
Measurement	1977[5]
Productivity environments	1984[6]
Risk management planning	1981[7]
Requirements engineering practices
Change board	1978[8]
Throwaway user interface prototyping	1975[9]
JAD sessions	1985[10]
Design practices
Information hiding	1972[11]
Design for change	1979[12]
Construction practices
Source code control	1980[13]
Incremental integration	1979[14]
Quality assurance practices
Branch-coverage testing	1979[15]
Inspections	1976[16]
Process improvement
Software Engineering Institute's Software Capability Maturity Model	1987[17]
Software Engineering Process Groups	1989[18]

Researchers have found that it typically takes 10 to 15 years for innovations new best practices to flow down the technology-transfer stream into common practice.^[19] If that's the case, the software industry's technology transfer cycle is seriously broken. Most of the best practices listed in Table 21-1 have been described in print for 15 years or more. Why aren't they being used?