Re: SBIRS, Ada and Ignorance

["Robert Klungle" <bklungle@adelphia.net>]

"Joseph Vlietstra" <joevl@earthlink.net> wrote in message
news:OKgrf.5742$mj1.1091@newsread3.news.pas.earthlink.net...
> Some answers about the SBIRS program.
> - The SBIRS program was plagued by poor initial systems engineering.
>    Those responsible have been replaced and we were able to get the
>    program somewhat back on track last fall.  We can't undo all of the
>    stupid mistakes but I think we can get at least 95% functionality.
>    (The more optimistic think we can score 100%)
> - Flight software is written in Ada 95 using Rational Apex compiler.
>    The only problems we've had with the development environment were
>    self-induced (e.g., attempting an Apex/ClearCase integration before
>    it was released by Rational).
> - We considered GNAT at the start of the project and contacted ACT.
>    For whatever reason, they weren't interested in developing a GNAT
>    compiler for us. (I don't think they realized that we would play
>    for the development.) In any case, we're happy with Rational Apex.
> - We also considered using a GNU C/C++ compiler but it ran slower
>    than the Rational Ada code.  This isn't an Ada is faster than C++
>    claim -- Lockheed-Martin spent a lot of money to have a good Ada
>    compiler available; the C++ compiler was an afterthought for the
>    hardware test group.
> - There were several subtle hardware glitches that required software
>    fixes.  This is a typical problem for a development program.
>    We all learned Chapter 13 of the LRM by heart.
> Anyone claiming that Ada was the problem is either ignorant of the
> circumstances or hoping to obscure the initial systems engineering
> problems.  In fact, Ada's language features allowed us to get as
> far as we have.
>
> Joe Vlietstra

Joe presents a good partial description of what happened.
There is a lot more to it which had nothing to do with coding.
Five major problems leading up to the situation were:
1. Incomplete and incorrect requirements through PDR (which was failed
previously.)
2. Incomplete and incorrect design mechanisms leading to individuals
designing the same thing more than once, not knowing what the others were
doing (multiple CPUs with similar functionality.) Eventually leading to a
system which would not perform (loss of messages) at 70% loading. The system
was completely redesigned from the ground up in a matter of 5 months. The
system is now heading for success (disregarding the usual integration
problems.)
3. Management chain failure due to little or no knowledge regarding software
development.
4. Incorrect or misleading design specifications on the SBC containing the
RH-32(s) from the supplier.
5. Low ball funding and late resource allocation to the project on the part
of the government and contractor(s).

I could continue with a very long list but you should get the idea.

Bottom line, Ada had nothing to do with the problem(s), and in fact actually
contributed to them having any success at all.

Incidentally, someone mentioned Wynne (in a later posting) casting
aspersions on Ada. He is getting his information from others who have a
specific agenda to remove Ada from the development list (been hearing it in
PDRs and PDAs). There is a general belief that "No one can find any Ada
developers. Ada is not being taught in schools. Systems Engineers and
Mathematicians coming out of school only know c++ and refuse to learn Ada."
Note this is a direct quote from a high level government person, which I
took issue with.

The problem of Ada(s) reputation and viability is very big and going down
hill rapidly, if observations are any indication.

Note I don't think this is a conspiracy, just a serious case of decisions
being made by the wrong people with little or no correct information.

cheers...bob