Does the DoD Really Want Reusable Software?
By Edward V. Berard (The Object Agency, Inc.)
Earlier, I posted a message about the roadblocks that the U.S. Department of
Defense (DoD) is placing in the path of software reusability. This message
describes a specific example of how an attempt to encourage the reuse of Ada
software on an actual DoD project is being thwarted. Neither the contractor (a
very large, well-known west coast aerospace firm) nor the contracting branch of
the service (the Navy) has said that software reusability is a bad thing. Both,
however, are prevented by well-established DoD regulations from both creating
and reusing "reusable software."
Brief Technical Analogy
In the computer hardware industry, reuse is the norm. For example, there are
standard CPU chips (e.g., M68020, Intel's 8088, and various versions of the
1750a). There are also standard RAM, mathematical co-processor, and ROM chips.
These, and other, chips are used in a wide variety of applications. A long time
ago, electronics engineers discovered that one of the most important axioms of
reusability was generality.
Unlike their software counterparts, electronics engineers do not have to
verify, for example, that every "op-code" supported by a particular CPU is
executed in a specific application. Nor do they have to demonstrate that every
last byte of RAM is utilized. While the reasons for this should be obvious, it
would be helpful to point out a few of them:
- Once a CPU chip is created and verified, a known (and typically very
high) level of reliability can be established for the chip. When this chip
is reused in another application, its known reliability can be factored
into a determination of the overall reliability of the new system.
[While a great deal is currently known about software reliability, much
more is known about hardware reliability.]
- If a change is introduced into the software which is running on a
particular CPU chip, specifically a change which now requires that a previously
unused "op-code" come into use, there is little need to replace (or alter) the
CPU chip. [Think of an Ada package as a chip, and the operations in its
interface as "op-codes." ] A similar argument could be made for the amount of
random access memory incorporated in a computer system.
- As new engineers are assigned to a project, it is likely that they may
have experience with standard, reusable chips. Even if they do not have
experience with the specific chips being used, there are certain fundamental
concepts which are common to particular classes of chips, and the new engineers
are likely to be aware of these concepts.
- With the demand for computer hardware (everything from embedded systems
to stand-alone computers) at an ever increasing high level, the cost and time
required to custom-design chips so that they are optimized for a specific
application is prohibitive. [Notice that since few organizations track
real software costs, that it is often difficult to make a similar
justification for not overly-customizing software.]
How does one apply the above analogy to reusable software? Consider the design
of a reusable software component. To be truly reusable, a software component
must be usable in some place other than its current specific application (or
part of an application). To increase the chances of this happening, the
software engineer must make the component more general. In fact, there are
well-known ways of increasing the generality of a software component to a very
Of course, there are trade-offs. Increasing the generality may decrease the
efficiency, or even increase the complexity. These, and other considerations,
must be balanced against such factors as the potential increased reliability
resulting from using a known verified component, and the cost and times savings
resulting from software reuse.
A Description of the Specific Problem
In the past year there has been no shortage of "software reusability"
presentations. Those of us on the "Software Reusability Circuit" seem to take
our show to an ever widening audience. If you have attended any software
reusability presentations, or if you have read any of the increasing numbers of
articles on the subject, you have probably noticed a pattern. Typically, the
presenter or author describes a "research project," or describes what sounds
like a good idea, but "hasn't yet been put into practice."
This points out one of the interesting human aspects of new technology. Since
introduction of new technology requires change, and human beings are, by
nature, conservative, it almost always takes a certain minimal amount of time
before new technology can actually be introduced into the workplace. So we go
about our "dance." We have meeting after meeting on the topic, and everyone
seems to be in general agreement (software reusability sounds like a nice
idea). However, nothing gets done until someone actually demonstrates the
validity of the concept on a "real" project.
At my company, we have both discovered (probably re-discovered) and
demonstrated some of the fundamental concepts of software reusability. Further,
since we often find ourselves in a teaching role, we try to communicate these
concepts to our clients during the normal course of our classroom instruction.
Almost always, our students have "real projects" to which they must immediately
apply the technology covered in our classes. As you are probably aware,
teaching in industry must be very pragmatic, and real world oriented.
Recently, one of us was describing how to increase the reusability of software
components during a class at the previously mentioned large aerospace firm. He
was informed that while the techniques he was describing might indeed increase
the reusability of Ada software, there were forbidden by specific DoD policy. I
asked the instructor to have the students document the problem. What follows is
- MIL-HDBK-272 requires that there be no "extraneous code" in a program that
is involved in the Nuclear Safety community. The "extra" functions which might
make a software component more general, and hence more reusable, are forbidden.
[Notice that this (unknowingly) trades off one kind of software reliability
(i.e., the increased reliability resulting from less code in the software
product) against another (i.e., the potential increase in software reliability
resulting from the use of a known, verified component.]
- C/SCSC - AFPRO/DCAA (Cost/Schedule Control System Criteria - AFPRO/Defense
Contract Audit Agency). There are audits to insure that the contractor is only
doing what the contract states. [This is part of a classic "Catch 22"
phenomenon. Specifically, it may be permissible for a contractor to reuse
software (although given the current hostile climate for " extraneous code,"
this may be difficult), however no new reusable software may be generated on a
project if it requires any generality outside of the scope of the immediate
- The original contract had no requirement for reusable software. If
any resources are expended on increasing the reusability of any of the software
components, the contractor will not be compensated for these expenditures.
[Another axiom of reusability is that the original design, implementation, and
verification of a reusable component are more costly than similar processes
carried out without reusability in mind. However, the more reusable the
component, the quicker the payback and the greater the future savings.]
- A particular danger, according to the contractor, (one that DCAA/AFPRO
will look for) is that if the contractor creates reusable software on a
cost-plus-fixed-fee contract, he may not reuse the software on a fixed-price
contract and charge the government (again) for the software. [This is an
interesting paradox. The government would rather pay the much larger cost of a
completely original piece of software, than be charged twice for the same
reusable software components -- even if the reuse of software components
results in a great reduction in the cost of a new product.]
- The cost of documenting and distributing the reusable software would not be
an allowable cost on any contract. [Here, I have no sympathy for the
contractor. This is merely a cost of doing business, and further, such costs
can be factored into the contractors fee.]
Both the DoD and the contractors which provide software to the DoD will have to
change the way they do business if they wish to realize the promised benefits
of reusable software. Much more thinking will be required on both sides. In the
end, governmental software policies will have to change, or their
interpretations will have to become more liberal. The contractors have as much
to change (if not more) than the government.
Software reusability, unlike a great deal of software engineering technology,
can show a payback in a relatively short period of time. I hope that both the
government, and the software community as a whole expend the time and effort