Re: Air Force using C coding standards to assess Ada projects

Re: Air Force using C coding standards to assess Ada projects

[Michael Feldman]

In article <CCn1oA.Fxp@world.std.com> srctran@world.std.com (Gregory Aharonian)
 writes:
>   I recently received the following piece of information that is so
>outrageous that I am almost tempted to put the Air Force at the top of my
>"we-aren't-interested-in-Ada" list, surpassing even ARPA's hostility
>to the language.
>
[GREAT story deleted]

Let me add my USAF horror story. Couple of years ago I was an expert witness
in a contract protest. Small Ada simulator, 10k lines, maybe $5 million to
produce. Details unimportant.

My client had proposed 10 LOC per day, end-to-end, based on their years of
doing similar programs in Fortran. It was explained to them that they lost
the award because their 10 LOC bid was OUTRAGEOUSLY optimistic, given that
an (unpublished, uncited) USAF guideline called for 3 LOC for systems of
this kind. It was a fixed-price award, so any productivity hits would have
been taken by the contractor anyway.

USAF claimed my client OBVIOUSLY did not understand the complexity of the
application (yeah, right - they had 25 years' experience doing simulators
in Fortran, successfully, at 10 LOC per day).

The case was heard by an administrative law judge. The lawyer who hired
me suggested that we try to assess how much the technical guy from USAF
knew. NOT the general who made the decision, just the techie who whispered
in his ear. 

The techie was a kid about 3 years out of a BSEE degree, with
a little Fortran experience. So we gave him a quick test: we wrote a
10-line program - find the max of a few numbers read from the console,
as I recall - in Ada, Fortran, and C, and asked the guy if he could
identify the languages. He got Fortran right; he identified _both_ Ada
and C as "Adatran." This was in a deposition a week before the hearing.

So we asked him that question when he was on the stand. Needless to say,
he blew it again. 

I don't expect generals to know low-level technical details. I _do_ expect
captains (I think he was a captain) in technical positions, where they are
giving technical advice to generals, to know _something._  Asked on the  
stand whether he had effectively decided this award, i.e. whether the general
just took his advice, he answered yes; so did the general. Asked on the
stand where he got the 3 LOC number, he could cite no written source;
he said "someone at Wright-Patterson said it was a useful rule of thumb."

On such bases, apparently, are contract awards decided in our services.
This has nothing to do with Ada, but it has everything to do with Ada.
The ignorance is BEYOND BELIEF.

Any more horror stories out there?

Oh, remember the one I told a while ago about the Navy officer, project
manager, who said he was inclined to go with C++ because "somebody told
me Ada could not do abstraction and information hiding"? 

Sheesh.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  co-chair, SIGAda Education Committee
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5253 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
"We just changed our CONFIG.SYS, then pressed CTRL-ALT-DEL. It was easy."
-- Alexandre Giglavyi, director Lyceum of Information Technologies, Moscow.
------------------------------------------------------------------------

RE: Air Force using C Coding Standards to Assess Ada Projects

[Bandor, Michael S. (SSgt)]

I passed around the posting that Greg submitted to several personnel in 
various offices in US Strategic Command (USSTRATCOM).  Based on their 
responses, I would say that Greg's source is either: a. sadly mistaken, or 
b. the evaluators/source got a hold of the wrong standards to evaluate their 
code by. I have "filtered" the responses to keep specifics about the sources 
somewhat anonymous.  Here are the responses that I received:

Response #1 (from SAF level):

    The information regarding the AFOTEC volumes is dated and the 
conclusions sent forth to Greg are just plain wrong.  I know for a fact that 
 AFOTEC has a method for specifically evaluating Ada.  I know because I was 
the chief of the methodology division that came out with it (back in 1990). 
 This coincided nicely with the direction that came out of Mr Mosemann's 
office for the AF policy on Ada.

     The only thing official is to look at the date/title of the evaluation 
pamphlet.  There have been updates to the pamphlets as the need arose.  I 
suspect someone didn't take the time to research what version of the 
pamphlet they had in their hands before blasting a loose cannon at the wrong 
target.  A responsible person would ensure that they checked to make sure 
they had the right method to apply to the evaluation as well as the most 
current version of the methodology.

     AFOTEC already knows about this message.  It's funny how such a 
credible software organization (that has been publicly praised by the other 
services as having the best software test methods around - so much that two 
of the other three services have torn off the AF cover and replaced with 
their own) is taking such a ripping over a poorly executed evaluation.


Response #2 (USSTRATCOM):

I'm always a bit skeptical when I see something from Mr Aharonian.  I think 
he tends to e-mail before he thinks sometimes.

I've worked with the AFOTEC people on creating a Vol 3 for Ada.  The 
publication was due to be finished late last year.  If a "C" Vol 3 was 
indeed used for the evaluation as stated in Mr Aharonian's message, I wager 
is was by mistake.  (As an aside:  I didn't know there was a Vol 3 that used 
"C" examples.  The original publication used until early this year had 
FORTRAN examples).  AFOTEC has made a concerted effort to incorporate 
Ada-related evaluation objectives into its procedures.  I think Mr Aharonian 
has been fed some bad data.




Mike Bandor, SSgt, USAF
NCOIC, Comm Gateway Software Engineering Team
Command Center Processing and Display System - Replacement
(CCPDS-R)
USSTRATCOM/J6454
Offutt AFB, NE

Internet/DDN:  STRATJ645@STRATHOST.STRATCOM.AF.MIL   or
                            BandorM@J64.STRATCOM.AF.MIL