munck@MITRE-BEDFORD.ARPA.UUCP (04/01/87)
It makes me crazy to see proposals for DoD reuse of software that use
terms like "standards and policies," "reusability plan," or "encourage."
It is the case that program officers are MOTIVATED to keep the project
on schedule and within budget during their tour of duty. Other things,
like the quality of the product and future costs to maintain it are
secondary. (Note, I'm talking about the motivation of these people by
the system, not necessarily their own predilections; I've seen many of
them fight the system to be allowed to make the product better, at some
cost to their own careers.)
If quality and life-cycle costs are secondary, the possibility of reuse
of the software on some later project is far down in the noise. The
results of a program office's doing a good job on reusability on one
project doesn't show up until the next project is nearly finished. Given
current development times, that's a half-dozen years or so; no way are
those original people, long re-assigned, promoted, or retired, going to
be rewarded. Please don't tell me that they would have been rewarded at
the time; that runs counter to the DoD's general policy of "don't make
waves" and institutional inability to make judgments about quality.
They know that they can get the same result by just going through the
motions, publishing the policies and having the reviews on schedule.
It's my opinion that the DoD will be unable to take advantage of
software reuse without significant institutional changes in the way it
acquires software. An idea like reuse has to be "owned" by someone, has
to be some person or group's major mission and goal. Moreover, that
someone has to have direct responsibility for acquiring the systems AND
have the money necessary. We can't continue to "tack on" reusability
the way we impose minority hiring on highway construction, attempting to
do two jobs with the same bucks and doing neither well.
My proposal is that software acquisition should be done on an
application-area basis instead of the current project basis. For
example, "avionics" might be a suitable application area. There would
be an Avionics Software Office set up with the responsibility of
acquiring the basic avionics software for all services for the next
fifty years. They would analyze the field of avionics, isolate
functions that are basic to it and the parameterization needed to make
packages tailorable to fit most circumstances, and procure the packages.
They would then supply software to particular projects, customizing
their standard packages where necessary by expanding the parameter-
ization to include the particular circumstances. A project might get
software from several Software Offices and fit it together like an
Erector Set. The software office personnel would be motivated to save
money and shorten schedules on projects by doing a good job of software
reuse.
It's a big change from the current way of doing business; I'm not sure
the bureaucracy is capable of such change.
-- Bob Munck