Four dynamics for bringing use back into software reuse

Software development organizations live or die based on how effectively they generate, assimilate, reuse, and leverage their knowledge. While there is an abundance of knowledge artifacts like code modules, program charts, system designs, and requirement specifications in such organizations, this overabundance is precisely what keeps reuse an elusive silver bullet. Two decades after the widespread commotion around reuse, its results in improving software quality, efficiency, and development agility have been dismal with no panacea in sight. Innovations such as object-oriented platforms—library-like repositories of standalone code fragments in reusable objects were touted as the solution to the reuse problem. The idea was that future developers would extract code from these "knowledge repositories" to efficiently retrieve existing solutions that match design problems. Coding a complex piece of software, in theory, would become much like putting together existing Lego blocks. In this article, we offer insights from field research in 25 software development organizations to highlight the two missing parts of the reuse knowledge management (KM) puzzle—recoding and redesign [6] (see the sidebar "How the Study was Conducted"). All organizations in our study had some sort of systematic reuse program in place. We must acknowledge that the sophistication of the reuse program differed across organizations. Some organizations were more advanced and mature in their reuse programs and systems than others. The findings we present here are those that were common across these organizations regardless of how sophisticated their reuse program was. Our findings provide interesting insights into what happens even when there is an organizational reuse mandate, regardless of the maturity of the reuse programs. The picture might be even grimmer if we consider the case of ad-hoc software reuse. Overall, the findings show that rookies are more likely to reuse software artifacts while experts refrain from doing so. More reuse occurs within than across software development groups. We also found that transient project teams are more likely to engage in reuse than permanent development teams