Software Reuse in the DoD: Lessons Learned

Presenter: Dr. Jeffrey S. Poulin
Track: 10
Day: Tuesday, 11 April 1995
Keywords: Software Reuse


This paper presents lessons learned from software reuse initiatives in the Department of Defense (DoD) [Ary93, Ary94, Pou94]. The paper illustrates the difficulties and benefits of program-to-program reuse as well as changes in current acquisition practices required to institutionalize this approach.

Lessons learned from attempting reuse across large programs

Many organizations have made attempts to promote software reuse within the DoD through the use of centralized reuse libraries and technology transfer programs. To date, these attempts have not produced large scale reuse opportunities nor associated savings. This paper describes an attempt to bring a different paradigm to promote software reuse. The effort planned organized and coordinated activity across two programs that could produce predictable savings with low risk. Rather than designers and developers randomly searching for suitable components, program-to-program reuse could result in an engineered, direct exchange of plug-compatible assets. This paper offers the following lessons for those attempting a similar effort:

Lesson #1 - Start early

To succeed in program-to-program reuse one must start early; it requires 6-12 months to establish a formal agreement between two programs. While many visionaries readily support the fundamental concepts of software reuse and its associated benefits [Pou93a], the majority of people actually working on DoD contracts remain highly skeptical of this new way of doing business. These people recognize the important unresolved issues in working with other programs and experience shows that they have well-founded concerns.

Lesson #2 - Address technical and managerial issues simultaneously

Many experts and organizations have addressed the technical and managerial barriers to software reuse. In program-to-program reuse these issues overlap. For the technical staffs to freely exchange ideas or software they first must have management support at many levels. The hierarchical culture within DoD contractors and the DoD itself demands that one address the concerns of each person who may see any possible effect of the effort. In general, staff members seeking to initiate reuse should not do so without the consent of their management and the management of their customers. Unfortunately, in the time it takes to obtain support and finalize a formal exchange agreement, architects may have to make design decisions which would inhibit reuse between the two programs. One must start early on both issues.

Lesson #3 - Start with architectures, not software

While most reuse programs focus strictly on software components, experience shows that other assets should come first. Reusing software from another program requires an understanding of the decisions that directed the design of that program's software architecture and its associated components. First, the use of individual software components often depends on the overall context in which they originally appeared. Exchanging these domain-specific design decisions must precede any exchange of software. A shared, common architecture for MIS would facilitate the reuse of software across programs. Second, technical exchanges and transfer of "lessons learned" will assure the engineers on the receiving program that the assets meet their needs and will help mitigate the tendency to reject assets due to the "not invented here" syndrome.

Lesson #4 - Build technical rapport

Program-to-program reuse works best with face-to-face working groups between developers and technical team leads. The agreements of upper level management and formal Memorandums of Understanding (MOUs) make the exchanges possible but do not necessarily make reuse possible. Technical rapport leads to understanding of each program's software, confidence in each other's products, and trust. Placing assets in a reuse repository in the hope that another program with find and use them cannot substitute for rapport between professionals. Future reuse efforts should focus on encouraging technical exchanges.

Lesson #5 - Acquisition policies must support reuse

Having a common, proven architecture would open the door for high levels of reuse on many future MIS systems. However, the tight schedules on programs and the natural tendency to focus internally indicates that these programs need support, encouragement, and incentives. Changes in acquisition policies need to address how the DoD approaches large scale reuse by providing guidance on how to implement and encourage reuse across future software development programs. For example, contracts should clearly state financial incentives (and penalties) for sharing resources with (or not supporting) similar programs.

Lesson #6 - Provide independent, continued support

In addition to written contractual agreements, program-to-program reuse initiatives need vigorous support from an independent arbiter outside both program offices. Because of increasing competition between programs for funds, parochial interests will still arise. An independent agency or executive office can ensure the programs continue to act in the best interests of the government.

Lesson #7 - Education

Education on program-to-program reuse issues may help resolve concerns but the education must take place well before making contact between programs. If this does not happen, the education will only consume time and not have an impact. The current DoD reuse education and courses offered by organizations such as the Defense Information Systems Agency (DISA) and the Army Reuse Center (ARC) can help by educating the all levels of program management of both government and government contractors.


In attempting program-to-program reuse within the DoD, many people ask questions for which there exists no easy answer. These questions often represent unacceptable risks to the programs involved in such a venture [End94]. Program Managers find these risks unacceptable because they encompass the DoD core metrics of schedule, cost, and quality. Once two programs agree to exchange assets they become dependent on each other. Who retains responsibility for a schedule slipping? Which program bears the cost of maintaining the assets? Will assets that become difficult to integrate reflect badly on one program or the other? Changes to acquisition policies can help ameliorate these questions.

The technical exchanges that provided the foundation for this effort succeeded in passing valuable experiences between programs. These experiences helped validate and influence the decisions that ultimately will lead to better, cheaper solutions for the Army customer. Future programs can also benefit from the lessons presented here to help make large scale reuse in the DoD a reality.


Arya, Pamela K., "Software Reuse on RCAS," Proceedings of the 6th Annual Workshop on Software Reuse, Owego, NY, 2-4 November 1993.

Arya, Pamela K., "The RCAS Software Architecture and Its Relation to Reuse," Tri-Ada'94, Baltimore, MD, 6-11 November 1994, pp. 388-395.

Endoso, Joyce, "Just say yes? RCAS execs decline to share code with SBIS rivals," Government Computer News, Vol. 13, No. 15, 18 July 1994, pp. 1, 69.

Poulin, Jeffrey S. and Joseph M. Caruso, "Determining the Value of a Corporate Reuse Program," Proceedings of the IEEE Computer Society International Software Metrics Symposium, Baltimore, MD, 21-22 May 1993, pp. 16-27.

Poulin, Jeffrey S., "SBIS Reuse Strategy," Loral Federal Systems Sustaining Base Information Services documentation, 22 March 1994, available from the Army Reuse Center (ARC) Defense Software Repository System (DSRS), (703)275-6368.

Dr. Jeffrey S. Poulin
Loral Federal Systems
MD 0210
Owego, NY 13827
Voice: (607)751-6899
Fax: (607)751-2597