Paige's How To Get An Automatic Ada Waiver memo

[srctran@world.std.com (Gregory Aharonian)]

     Sometime ago DoD Secretary Perry issued a policy memo encouraging the
use of COTS products in defense systems (as opposed to MIL-SPEC equipment).
As Ada is a MIL-SPEC, the few in the DoD who actually pay attention to the
Ada Mandate questioned whether Perry's memo would undermine the Ada Mandate.

     To qualify this issue, Ass. Sec. Paige and Und. Sec. Longuemare issued
another memo attempting to clarify this issue and try to show that Perry's
memo is not in conflict with the Ada Mandate.  Strangely, their joint memo
of August 26 not only does not clarify the issue, but provides a perfect
mechanism for getting an automatic waiver for the Ada Mandate.  Their memo
does reflect how out of touch senior Defense officials are with what is going
on in the software world.



     In their memo, Paige and Longuemare write:

     "It is DoD policy to use commercial off the shelf (COTS) software
     whenever it meets our requirements.  However, when COTS software is
     not available to satisfy requirements and the DoD must develop
     unique software to meet its needs, that software must be written
     in Ada in accordance with 3405.1 and 5000.2"


This is a meaningless sentence because no where is software COTS defined,
opening up a loophole wide enough to float an aircraft carrier group through.
Most likely, when these guys think of COTS, they are thinking about packages
like 1-2-3, Wordperfect, DBASE, etc, the very narrow definition of COTS.
However, think of the average Defense application, which will have software
requirements for user interfaces, graphics, database, communications,
networking, signal/image processing, and real time control.  For all of
these requirements, there are ample numbers of COTS source code/object code
libraries available in C/C++ and Visual Basic. So if one defines COTS software
in a wider sense as to include COTS source code libraries, then the effect of
Paige and Longuemare's memo is to encourage the use of these non-Ada COTS
source code libraries as a substantial part of Defense programming project. 
But at least these types of COTS libraries are fairly well documented and
tested.  Not so if one interprets their memo in the loosest sense.  There
are a few CDROM publishers who scoop up tons of source code from the Internet
and make it available cheaply (Prime Time Freeware for example, which sells
an Ada CDROM).  In a loose sense, a CDROM is COTS software, since it is
commercially available off the shelf and shrinkwrapped.  But even I would
argue that this type of stuff doesn't belong anywhere near DoD systems.

     But because Paige and Longuemare don't define COTS, DoD programmers and
contractors are free to choose whatever definition they want without any fear
for retribution.  This paragraph then does nothing to clarify Perry's memo.
In fact, I could start a business where contractors could write code for
whatever they want and send it to me.  I would add some marginal value, shrink
wrap some diskettes, put it on my shelf, and sell it back to the contractor,
who could then validly argue that the software is COTS.



     However, all of these non-Ada COTS libraries still need "glue", which for
the most part has to be newly written code that you would expect to fall under
3405.1 and 5000.2 and be in Ada.  However, another part of their memo provides
another loophole wide enough to push the Pentagon building through.  I quote:

     "Use of other programming languages can be considered if proposed
     by a contractor as part of his best practices since waivers to the
     use of Ada can be granted, where cost-effective, in accordance with
     procedures established in the policy referenced above.  However,
     such proposals require strong justification to prove that the overall
     life-cycle cost will be less than the use of Ada will provide".

Again, another meaningless requirement, in this case, because of the lack of
a definition for proving cost-effectiveness.  Given the almost non-existent
number of independently verified measures of Ada's cost-effectiveness (as
opposed to scores of ancedotal reports), one could justify the waiver on the
same grounds by citing ancedotal evidence supporting their language choice.
But for most contractors, that is too risky of an argument.

Instead, contractors can turn to the leading Ada vendor for a court-proof
valid justification.  Remember that contractors need this justification to
get out of writing the "glue" software in Ada.  However, given the large
size of the COTS libraries they will be "gluing", the amount of "glue" code
will not be large, usually under 100,000 lines of code, if that.  But thanks
to the language-schizo folks at Rational, a ready waiver justification is
on hand.  For if you read Rational's literature and technical reports, they
repeatedly argue that with Rational's tools that you can program as cost
effectively over the life cycle in C++ as you can in Ada (especially if you
supplement Rational's C++ tools with Alsys/Telesoft's C++ GUI tool, Tartan's
C++ signal/image processing libraries, and Intermetrics C/C++ realtime tools).
Thus all you have to do is cite this collective tool set to argue for your
waiver.  Since the DoD would publicly have to dispute the non-Ada assertions
of its leading Ada suppliers (extremely unlikely since only unkind words are
said about Greg), then this waiver argument will fly through unopposed.  At
that point, you can then argue the equivalence of CASE tools to not use the
above companies' products and use whatever tools are on hand.  As a butress
for this argument, you can include TRW's comment from the Ada/C++ Business
yes-man study that by the mid-1990's, C++ would be as cost effective as Ada.
And if that fails, call in whatever favors you have at ARPA, and ask them to
explain to your contractor officer why Ada is a lousy language.

Even better is that some companies like TI(IEF) and Oracle(CDE) have graphical
environments where you "paint" much of the glue code, structured diagrams that
their tools either execute or convert to code.  One could argue in the broad
sense that these "paintings" aren't source code and therefore not subject to
3405.1 and 5000.2.



    In summary, because Paige's and Longuemare's memo do not explicitly define
"COTS" and "cost-effective", they provide loopholes that make it extremely
easy to get an Ada waiver, for those who bother to worry about doing so.
Mostly likely these two senior officials are unaware of much of what is
happening in the software industry (especially if the only trade shows they
go to are Tri-Ada), and don't realize that the lack of definitions for these
two terms makes their memo a blueprint for obtaining automatic Ada waivers.

    So the issue of Perry's memo is still unresolved, providing no guidance
to those who care about Ada, and providing yet another negotiating tools for
those who don't care about Ada.  As long as the DoD refuses to encourage open
critical discussion about these issues, this confusion will continue to 
undermine Ada acceptance in the DoD.  As taxpayers, we should all demand 
better memos from such senior officials.

    In a related example of senior confusion, in the October 1994 Crosstalk
(where Paige and Longuemare's memo was published), there is another rah-rah
Ada article from AF Dep.Ass.Sec Mosemann on how great Ada is, where he once
again pledges his undying love for Ada.  Unfortunately, it conflicts with
his earlier memo on Air Force use of AI where he didn't mention Ada once, it
conflicts with his refusal to comment on why the Air Force's KBSA project is
allowed to continue being mostly non-Ada, and most ironic, in this very same
issue of Crosstalk there is an article from Air Force people at Rome Lab
(home of KBSA) on Rapid Prototyping in which the example used in the article,
a program for space debris, is written in C.  I guess the DoD has two Air
Forces.  Don't any of you guys talk to each other?

    But hey, have fun singing songs at Tri-Ada.

Greg Aharonian