From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 required=3.0 tests=BAYES_00,LOTS_OF_MONEY,
	TO_NO_BRKTS_PCNT,T_MONEY_PERCENT autolearn=no autolearn_force=no
	version=3.4.5-pre1
Date: 2 Dec 92 16:38:23 GMT
From: eachus@mitre-bedford.arpa  (Robert I. Eachus)
Subject: Re: Open Systems closed to Ada?
Message-ID: <EACHUS.92Dec2113823@dr_no.mitre.org>
List-Id: <comp.lang.ada>

In article <1992Dec1.230732.13822@fcom.cc.utah.edu> val@news.ccutah.edu (Val Ka
rtchner) writes:

   Nevertheless, you have been, inadvertantly, making my point for dropping The
   Mandate.  (I know, we won't agree on this either.)  However, you have made
   my point for freedom in language choice.  There are those outside the DoD
   that use Ada without The Mandate, and those inside the DoD which don't use
   Ada despite The Mandate.  Any opinions to the contrary don't face reality.

   Face reality.  The goevernment spent a lot of money developing Ada
because it NEEDED a language which would significantly reduce
maintenance costs on long-lived embedded computer systems.  This was
the primary goal of the HOLWG, and there is overwhelming evidence that
Ada more than meets this goal.  In 1976 or thereabouts the DoD spent
only 8% of the money spent on software on development and most of the
rest on maintenance.  Tripling the amount spent on development to cut
the maintenance cost by 50% would have been a good thing.  Ada comes
closer to a factor of ten drop in maintenance costs while also
decreasing development costs.

   Now you come along and say that, yes Ada reduces development costs
over CMS-2 and JOVIAL, but we can reduce them further with C++.  The
DoD of course responds that the don't give a flying #$%&, in their
environment maintenance costs dominate, and there is NO evidence that
maintenance costs would be lower with C++.  In fact, right out of the
gate, you are asking them to support at least two languages, because
there are applications for which C++ is totally unsuited.  The DoD
knew and knows that it pays a penalty by insisting on a single
language that can be used for both flight guidance systems and payroll
applications.  The advantages--to the DoD--of having a single language
for both outweigh the costs--to them.

   So stop bitching aobut "the MANDATE" for the wrong reasons.  If you
can show that--for a given system--the cost of using some other
language is less over the ENTIRE life of the system, any branch of the
DoD is willing to listen.  But to save a million dollars up front by
spending an extra 20 million over the next 20 or 30 years is just not
cost effective.

   I have already seen both sides of the coin.  I've seen cases where
the use of Ada allowed major changes to the hardware to be
accomplished at little or no cost after software development was
complete.  I've seen Ada systems where the biggest maintenance concern
was that since all the work could be done by one person, there would
be a lack of continuity.  I've also seen systems which got waivers not
to use Ada and which either failed to very get fielded because the
computer hardware was obsolete by the time the system was finished and
the cost of modifying the software to fit new hardware was too high,
or where the DoD is evaluating the cost of completely rewriting the
system in Ada to reduce maintenance costs.  (C-17 is an example of
this--see the GAO report...)

   Now if the DoD already knows of--literally--billions of dollars
that went down the tubes because Ada was not used, I think you can
start to understand their position.  Given my position, I'm not going
to put together a list of the top ten DoD software disasters for the
last decade--you can if you want.  However, if I put together a list
of the top ten reasons why DoD software projects failed, I think that
inappropriate Ada waivers (or ignoring the mandate) would be about
third or forth.  The first is going out for bid with an inadequate set
of requirements (RFP and/or A-spec).  The second is probably allowing
software PDR (preliminary design review) completion to drag out and
allowing coding to start before the design is approved.  Where
unrealistic schedule falls on the list depends on whether you regard
it as mostly a problem or a symptom.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...