By Edward V. Berard (The Object Agency, Inc.)Nearly two decades after Doug McIlroy described the need for a software components industry, software reusability is finally receiving some attention. One of the promises that the U.S. Department of Defense (DoD) made when it introduced the Ada programming language and its associated technology, was that Ada would help to facilitate software reusability. Apparently, someone within the bowels of the DoD feels that software reusability is an important issue.
A quick study of the possible benefits of reusing software reveals that there is much more to be gained than a simple cost savings during the development of a software product. For example, the reuse of a software component which is known to be reliable introduces less risk than re-designing and re-coding the same component for each new application. Efficiency issues can also be more effectively addressed if one can focus attention on optimizing a set of reusable components rather than having to continually re-optimize newly re-coded versions of previously existing modules.
However, it seems that both the DoD and their contractors are greatly confused about just what an increased emphasis on software reusability might mean. While they both might acknowledge that some existing software development practices will have to change, they seem unaware of which specific items will be different. There are a number of very large roadblocks to software reusability on DoD projects, and it should be useful to mention a few of them.
One of the largest roadblocks to software reuse is the cost-plus-fixed-fee (CPFF) style of contract now commonplace among DoD contracting styles. In effect, the more people a contractor can place on a project, the greater the financial reward. Hence there is a great incentive to "re-invent the wheel." While fixed-price contracts would go a long way towards fixing this "problem," we need to examine other alternatives.
Current and past DoD software development standards (e.g., DOD-STD-2167, 490, 1679A, etc.), or their interpretations, are another set of roadblocks to software reuse. While the words "software reusability" might be "buried in the DIDs" (Data Item Descriptions), the standards themselves discourage software reuse on a number of fronts, e.g.,:
While the DoD has standards of acceptance for reusable hardware, there is little in the way of standards or certification mechanisms for reusable software. For example, there is no currently existing organization charged with certifying software for reuse. Yes repositories of "reusable" software exist, but there is no generally recognized (much less mandated) certification mechanism for reusable software components (e.g., an Ada Component Verification Capability (ACVC)).
In the past year, I have given a number of presentations on software reusability. During the discussions which followed these presentations, I became acutely aware that either the DoD was actively discouraging the concept of software reuse or that the contractors (and the DoD) did not know that an increased emphasis on software reuse would involve significant changes in the state of the practice.
Until both the DoD and their contractors come to grips with the fact that software reusability does not mean business as usual, software reusability will be relegated to the status of a buzzword.