On Mon, 11 Nov 1996, Brian A Wichmann wrote:
> I agree with Tuck. I can take another example from NPL. We use
> LabView a lot since it provides 90% of the application as COTS
> in effect by providing device drivers and use interface code
> for control of instruments. I would not dream of attempting to
> convert them to Ada *unless* the volume of code to be written
> by them was much larger than is typically the case. We must
> not over-sell Ada.
> Brian.
I agree that COTS, under many circumstances is the preferred
choice. I also agree that we should not arbitrarily convert
working code to Ada just to use Ada. Mature code that works is
usually better than new code that has not been "burned-in" regardless
how good the new technology may be. That is why some of our
customers appreciate Annex B and pragmas Import and Export.
However, COTS should be COTS rather than a way to to sneak around
the use of Ada. If one is going to use a COTS product, it should
be used as is. In this respect, an Ada compiler itself is COTS. And
one can easily see that generic reusable Ada components such as GRACE
could be considered COTS.
Some COTS products include a programming language. Often, a programmer
will decide to use that programming capability to make modifications
to the COTS product. One little modification leads to another and
another. Soon we have fifteen thousand lines of source code written
in this "COTS" product, and a huge effort in maintenance.
Other COTS products require "integration" activity. We all know
what problems can occur during integration. And everyone has a
scary story that can be told as we sit around the campfire about
the mischief of ghouls and goblins during systems integration.
All this being said, no one is denying the virtue of COTS when COTS
is appropriate. No one in this discussion has ever suggested writing
a DoD-specific word processor, competing with Microsoft on Windows NT,
or recoding Oracle in Ada. What we have been saying is that the DoD
should not diminish its support for Ada, and should not abandon its
current policy. What we are saying is that the failure of Ada in
the DoD may be symptomatic of a much larger problem related to the
management of software within the DoD. If we cannot manage something
as straightfoward as the Ada single-language policy, what makes us
think we will be any more successful managing a multi-language policy
that raises the complexity of the decision-making process for a
software project process well beyond the understanding of the average
program manager. And that complexity, when it finally overwhelms the
program manager, will inevitably default to "bumper-sticker"
decision-making. Those who believe that anyone will engage in a
thoughtful process on this issue, while correct in their idealism,
are excessively optimistic about the actual process.
COTS, of proven quality, should be the choice when it is actually COTS.
Ada should continue to be the default for programming. Ada should also
be the default for programming that requires integration with other
environments, including COTS. When one wants to use some other language
for programming, we should continue to require justification for the
use of that language.
I do not understand why this simple policy seems difficult.
Richard Riehle
|