The Software Engineer: Skills for Change

During the past 15 years, the Defense Science Board (DSB, www.acq.osd.mil/ dsb) has made more than 130 recommendations intended to improve the ability of software engineering organizations to produce high quality software on time and at cost, yet these organizations continue to find it difficult to make these changes. If improvement were simply a matter of purchasing a new software tool, change would not be so difficult. But to realize the improvements called out in the DSB reports and others like them requires changes in the day-to-day practices of software engineers and their managers. Achieving these kinds of changes requires more skills than the ability to purchase a new tool – skills for change management become important. Unfortunately, too few of the software-intensive organizations are proactive about managing change. A recent article by Boehm and Basili shows that poor software engineering practices are still a major contributor to software defects [1]. While some organizations adopt new and better software engineering practices and technologies because they recognize their strategic value, most organizations are more reactive than proactive. Reactive organizations are at the mercy of change led by others, and generally attempt radical improvements in their software engineering disciplines only after customer pressures or disaster. By then, this catch-up game is costly and is often implemented by pick-up teams of individuals who may be well intentioned, but lack the change management skills to be successful. The most common result is money spent with little change to show for it.

[1]  Bill Broyles Notes , 1907, The Classical Review.

[2]  Barry W. Boehm,et al.  Software Defect Reduction Top 10 List , 2001, Computer.

[3]  Clayton M. Christensen The Innovator's Dilemma , 1997 .