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

[mccall@mksol.dseg.ti.com (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.