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