Ada scandal makes front page of Wash. Post business section

Ada scandal makes front page of Wash. Post business section

[news]

 
The Ada programming language made the front page of the business section
of the Washington Post on March 8 this week.  The article was titled
"Out-of Control Contract"...  a fitting title.  It concerns the gigantic
IBM contract with FAA to ensure the safety of air travellers by writing
the next generation of air-traffic control software in Ada.  Describing
the overall situation as FUBAR would be a kindness to the parties
involved.
 
Some quotes from the article:
 
    "In an unusual and painful admission, IBM concedes it short-circuited
    its own testing procedures as it tried to meet deadlines.  The result
    was a series of bugs in  preliminary versions of the computer network
    -- a system in which an error could cause a deadly plane crash."
 
Of course, this is a real-world consideration.  None of these
contractors wants to look bad or get shit-canned and have to go job
hunting.  Make their lives hard enough and impossible enough (by
insisting that they use an impossible programming language, for
instance), and you have short-circuited technical tests, and that means:
 
 
 
WHHHHHEEEEEEEEEEEEEeeeeeeeeeeeeeeeeeee....   SPLOWIE!!!!!!!
 
    "...many programmers had to learn the new language from scratch."
 
Another real-world consequence of swimming against the tide.  C and C++
programmers are not hard to find, but IBM, the world's largest computer
company, apparently couldn't find Ada programmers.  That means that  the
only thing standing between you and another aircraft moving at 600 mph
will soon be a first-time-ever Ada programmer:
 
 
WHHHHHEEEEEEEEEEEEEeeeeeeeeeeeeeeeeeee....   SPLOWIE!!!!!!!
 
 
   [..description of design change requirements, midstream] "Over two
   years, there were close to 600 such changes."
 
Another real world consideration, as opposed to Ada, which is part and
parcel of an entire deluded system of thought, whereby software
development is viewed as an engineering discipline much like building a
skyscraper.  This means total design from the highest level of
abstraction down to low-level PDLs and that, when code is written for
the lowest level PDLs, the project is finished and you move on to the
next project.  The ludicrous assumption being made is that all
parameters of a large task can be known perfectly before a line of code
is ever written.  Smalltalk, C, C++, Pascal, and other modern languages
can all be used for fast prototyping;  The 600 midstream changes would
present no particular nightmare.  Ada, of all programming languages,
appears to be the one which has the most difficult time with prototyping
and, in fact, appears to be adapted, in theory at least, only to a
rather tiny class of problems for which all parameters can be known in
advance.  For anything else, including airplanes:
 
WHHHHHEEEEEEEEEEEEEeeeeeeeeeeeeeeeeeee....   SPLOWIE!!!!!!!
 
 
   "Another reason for the delay was IBM's lack of adequate software
   tools..."
 
Whoa!  For $5 billion dollars, the worlld's largest computer company
couldn't buy programming tools?????  I assume here that they mean such
things as compilers, linkers, editors, debugging tools, profilers...
all of the sorts of things I just order from the Programmers' Connection
for $200 or $300 whenever I need them.  You say you can't find these
sorts of things for Ada after 13 years, even for 5B dollars (my understanding
is that a billion is a thousand million)????
 
That's going to put a lot of projects behind schedule, and that's going
to cause a lot of technical tests to be falsified:
 
WHHHHHEEEEEEEEEEEEEeeeeeeeeeeeeeeeeeee....   SPLOWIE!!!!!!!
 
 
To the people responsible for Ada who might be reading this, I would
recommend sepuku.  To anybody else, I would recommend the purchase of
stock in steamship lines and railroads.
 
 
 
 
 
 
-- 
Ted Holden
HTE

Re: Ada scandal makes front page of Wash. Post business section

[fred j mccall 575-3539]

In <335@fedfil.UUCP> news@fedfil.UUCP (news) writes:


> 
>The Ada programming language made the front page of the business section
>of the Washington Post on March 8 this week.  The article was titled
>"Out-of Control Contract"...  a fitting title.  It concerns the gigantic
>IBM contract with FAA to ensure the safety of air travellers by writing
>the next generation of air-traffic control software in Ada.  Describing
>the overall situation as FUBAR would be a kindness to the parties
>involved.
> 
>Some quotes from the article:
> 
>    "In an unusual and painful admission, IBM concedes it short-circuited
>    its own testing procedures as it tried to meet deadlines.  The result
>    was a series of bugs in  preliminary versions of the computer network
>    -- a system in which an error could cause a deadly plane crash."
> 
>Of course, this is a real-world consideration.  None of these
>contractors wants to look bad or get shit-canned and have to go job
>hunting.  Make their lives hard enough and impossible enough (by
>insisting that they use an impossible programming language, for
>instance), and you have short-circuited technical tests, and that means:

Note that this has nothing to do with Ada.  This 'real world
consideration' happens no matter what language you are using.  If you
don't test it, it may be broken.  Seems to apply everywhere to me.

> 
>    "...many programmers had to learn the new language from scratch."
> 
>Another real-world consequence of swimming against the tide.  C and C++
>programmers are not hard to find, but IBM, the world's largest computer
>company, apparently couldn't find Ada programmers.  

Just like any change of language.  By this reasoning, Ted, we should
all still be programming in COBOL because that's what people know.
Any competent software engineer ought to be able to learn a new
language in fairly short order.  If IBM didn't take this into account
when they set up the schedules, that explains your 'schedule crunch'
and the subsequent inadequate testing, not the mere fact that they
were using Ada.

> 
>   [..description of design change requirements, midstream] "Over two
>   years, there were close to 600 such changes."
> 
>Another real world consideration, as opposed to Ada, which is part and
>parcel of an entire deluded system of thought, whereby software
>development is viewed as an engineering discipline much like building a
>skyscraper.  This means total design from the highest level of
>abstraction down to low-level PDLs and that, when code is written for
>the lowest level PDLs, the project is finished and you move on to the
>next project.  The ludicrous assumption being made is that all
>parameters of a large task can be known perfectly before a line of code
>is ever written.  Smalltalk, C, C++, Pascal, and other modern languages
>can all be used for fast prototyping;  The 600 midstream changes would
>present no particular nightmare.  Ada, of all programming languages,
>appears to be the one which has the most difficult time with prototyping
>and, in fact, appears to be adapted, in theory at least, only to a
>rather tiny class of problems for which all parameters can be known in
>advance.  

Again, this has nothing to do with language.  If the customer declines
to freeze the requirements, you're going to take it in the neck no
matter *what* language you are using.  The real failure here was that
IBM didn't make them freeze the spec and renegotiate schedule when
they elected to change it.  If they had, while the software might be
behind its original schedule, the reason for that (poor management
practices, apparently on both sides) would have been obvious.
Instead, from what you write it appears that IBM was left shooting at
a moving target.  This is a recipe for disaster in *any* language and
would seem to explain why they found themselves forced to try to cut
corners on testing.

As for all this rhetoric about how Ada is 'assuming' things that other
language don't assume, it strikes me as the sheerest hogwash.  If you
think the up-front knowledge required to design a decent Ada system is
extensive, you have never attempted to produce a large system in C++.
Once again, in order to produce anything other than an unmaintainable
and bug-ridden mess, you are going to have to do a lot of up front
work to define things.  There is nothing particular about Ada in this
regard. 

> 
>   "Another reason for the delay was IBM's lack of adequate software
>   tools..."
> 
>Whoa!  For $5 billion dollars, the worlld's largest computer company
>couldn't buy programming tools?????  I assume here that they mean such
>things as compilers, linkers, editors, debugging tools, profilers...
>all of the sorts of things I just order from the Programmers' Connection
>for $200 or $300 whenever I need them.  You say you can't find these
>sorts of things for Ada after 13 years, even for 5B dollars (my understanding
>is that a billion is a thousand million)????

In the U.S., yes.  And this sounds more like a management problem than
anything else, since such tools are certainly available.  Perhaps IBM
was in a situation where they were trying to produce the tools for
their platform and then use those tools?

In any case, your assault seems to have tenuous reality behind it, at
best.  So why not leave the language flames somewhere else?  I've
redirected follow-ups appropriately.

-- 
"Insisting on perfect safety is for people who don't have the balls to live
 in the real world."   -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred.McCall@dseg.ti.com - I don't speak for others and they don't speak for me.

Re: Ada scandal makes front page of Wash. Post business section

[David Emery]

<Normally I don't respond to Ted's ravings, but there's a point I'd
 like to make here.>

One of the interesting things we've noticed over the last few years as
our contractors started using Ada is that it's easier to spot
disasters.  It used to be that we wouldn't discover that a program was
totally screwed up until close to delivery.  Now, we can tell pretty
early into the program when it won't make it.  We still don't know
what to do about it, but at least the problems become visible earlier.

In many respects, Ada is to "blame" for this, because Ada makes it
easier to see the design, or lack of design, in the software.  This
isn't just a feature of Ada, but Ada helps significantly.  

The morale of the story is that bad programmers can screw up using any
language.  Ada just makes this more visible.

				dave

Re: Ada scandal makes front page of Wash. Post business section

[Bill Kinnersley]

In article <EMERY.93Mar12101548@dr_no.mitre.org> emery@dr_no.mitre.org (David Emery) writes:
: <Normally I don't respond to Ted's ravings, but there's a point I'd
:  like to make here.>
: 
: The morale of the story is that bad programmers can screw up using any
: language.  Ada just makes this more visible.
: 
It seems to me that the easiest way to refute this well-publicized example
is by giving a counterexample.  Is there a project that you can point to 

  a) Of comparable size, complexity and importance
  b) Ada was used
  c) The programmers were happy
  d) The customers were happy
  e) Modifications were easily made
  f) The project came in on time

-- 
--Bill Kinnersley
  billk@hawk.cs.ukans.edu
226 Transfer complete.

Re: Ada scandal makes front page of Wash. Post business section

[David Emery]

>It seems to me that the easiest way to refute this well-publicized example
>is by giving a counterexample.  Is there a project that you can point to 

>  a) Of comparable size, complexity and importance
>  b) Ada was used
>  c) The programmers were happy
>  d) The customers were happy
>  e) Modifications were easily made
>  f) The project came in on time

A couple of examples come to mind:
	AFATDS (although I'm not sure about the delivery schedule)
	STANFINS
Both of these systems are multi-million lines of code, and both have
received substantial exposure in the trade press.

Locally, we have two systems, CCPDS-R and Cobra Dane, in the 150k-500k
range that have come in under schedule and budget using Ada.

None of these programs have all of the characteristics of FAA-AAS.  I
personally think that things the size of FAA-AAS may not be doable at
all.  I certainly believe that, if it can't be done in Ada, it can't
be done.  

				dave

Re: Ada scandal makes front page of Wash. Post business section

[Robert I. Eachus]

     I just saw some more information on the problems with the FAA
enroute system, and concluded you would have to be seriously crazy to
even attempt some of the "requirements changes" on this contract in
any other language.

     The FAA moderization is in two parts.  The tower/approach systems
upgrade has completed development and is considered a major success.
However, when the enroute system was started it was to provide
upgrades to the 14 enroute centers and run on mainframes.  It is now
supposed to support a smaller number of centers (with larger
workloads) by distributing most of the work to individual RS/6000's
for each controller. (I think the decided to close 6 enroute centers,
then reconsidered some after the Long Island site was hit by the Ma
Bell crash.)

     Current (published) projection is that this will cause a 14 month
slip in the enroute PROGRAM at the same contracted cost, but IBM wants
a guarentee of no more major changes.  Wouldn't you?  The articles I
saw implied that the redistribution of functionality was not a
problem, but the FAA did not want to deploy the system until the
support documentation and test tools for the new workstations were
done.  (I don't even know if the test tools are hardware or software.)
Anyone in the trenches want to add more?


--

					Robert I. Eachus

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

Re: Ada scandal makes front page of Wash. Post business section

[Robert I. Eachus]

In article <C3sFnI.6ws@hawk.cs.ukans.edu> billk@hawk.cs.ukans.edu (Bill Kinnersley) writes:

  > It seems to me that the easiest way to refute this well-publicized example
  > is by giving a counterexample.  Is there a project that you can point to 

  >  a) Of comparable size, complexity and importance
  >  b) Ada was used
  >  c) The programmers were happy
  >  d) The customers were happy
  >  e) Modifications were easily made
  >  f) The project came in on time

    The FAA tower/terminal upgrade involved the same contractor, the
same language, the same tools, and the same client.  It was somewhat
smaller (one million lines of code vs. 1.5 million) but a significant
amount of the code is shared between the two projects.

    I believe that project meets all of your requirements except f).
I'm not sure about completion, but the initial installation was about
three weeks late because the FAA wanted to spend some additional time
on testing and closing bug reports.  (I wasn't there...but I've talked
to people who were.  I don't question the decision to miss the
schedule, but my understanding is that the concern was with "warm
fuzzies" rather than any known serious bugs or any found during the
testing. It could have been deployed on schedule, but everyone was a
lot more cofortable with few more weeks to check things out.))

    As I've pointed out elsewhere there are a lot of other ATC systems
in Ada, which meet all the criteria except size.  (They are about half
the size of the US system or smaller.)


--

					Robert I. Eachus

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

Re: Ada scandal makes front page of Wash. Post business section

[Charles H. Sampson]

In article <C3sFnI.6ws@hawk.cs.ukans.edu> billk@hawk.cs.ukans.edu (Bill Kinners
ley) writes:
>In article <EMERY.93Mar12101548@dr_no.mitre.org> emery@dr_no.mitre.org (David 
Emery) writes:
>: The morale of the story is that bad programmers can screw up using any
>: language.  Ada just makes this more visible.
>: 
>It seems to me that the easiest way to refute this well-publicized example
>is by giving a counterexample.  Is there a project that you can point to 
>
>  a) Of comparable size, complexity and importance
>  b) Ada was used
>  c) The programmers were happy
>  d) The customers were happy
>  e) Modifications were easily made
>  f) The project came in on time

     I'm sure that this won't satisfy you, particularly since I can't
verify your requirement a.

     A few weeks ago I was on a pro-Ada panel with Bruce Krell of Hughes.
Bruce is a software project manager whose group works 40% in Ada and 60%
in <other language>.  He says (paraphrase) that, all other things being
equal, he would prefer to use Ada rather than <other language>.  The rea-
son?  "Projects in Ada come in on time; projects in <other language>
don't."  Although he didn't specifically address your points c, d, or e,
the implication was that more than just the schedule was satisfied.

     In case you're wondering why he does 60% of his work in <other lan-
gauge>, he says that, among other things, he often has to work in environ-
ments that don't have an Ada compiler.  That's a different issue, and one
that's often been discussed in this newsgroup.

				Charlie

Re: Ada scandal makes front page of Wash. Post business section

[news]

In article <EMERY.93Mar12101548@dr_no.mitre.org>, emery@dr_no.mitre.org (David Emery) writes:
*<Normally I don't respond to Ted's ravings, but there's a point I'd
* like to make here.>

*One of the interesting things we've noticed over the last few years as
*our contractors started using Ada is that it's easier to spot
*disasters.  It used to be that we wouldn't discover that a program was
*totally screwed up until close to delivery.  Now, we can tell pretty
*early into the program when it won't make it.  We still don't know
*what to do about it, but at least the problems become visible earlier.

You mean like when a prototype due in 1990 is still a year out  (so they
say) in 1993?  Can you imagine where we might be (actually, in a Japanese
coal mine in West Virginia) had we had that sort of fast recovery time for
projects in 1941?

It gets easier to spot disasters when there are more of them to spot...
you get more practice at it.  People watching Ada disasters should be
getting awfully good at spotting disasters by now.



-- 
Ted Holden
HTE