Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[mcq95@earthlink.net (Marc A. Criley)]

"soft-eng" <softeng3456@netscape.net> wrote in message news:9fa75d42.0305141747.5680c577@posting.google.com...
> I don't agree that Ada is likely to be particularly useful
> for catching errors in a professional environment -- say 2-3%
> of the actual errors at best.  If it's catching more than
> that, I don't see how you can have good people.
> 
> But good people can certainly make projects succeed using
> many kinds of tools, including Ada.

Now waitaminnit.
 
First we read a recommendation for software development success that
consists of "1)  Hire good people, and give them the tools they need."
Since that was the extent of the advice, presumably that's the
foundation for success. And given the nature of this debate, it is
being argued that the Ada programming language is not to be considered
an inherently good tool that aids success (from a purely technical
perspective).
 
And that, in contrast, one would be hard-pressed to achieve success if
one believes that "2) [...] You just need to give them a quality
solution, and quality will follow.  Just tell them what to do and make
sure they do it.  [...] For instance, a militaristic language that
will catch all their errors and solve the problem of human
fallibility.  Or a methodology that will make quality flow out their
ears.  Typical command-and-conquer stuff is "now everybody will write
a spec in this here format before starting a new module." [Excisions
done with care.]
 
But, but, we did achieve success! We had a quality architecture and
design that took advantage of Ada's technical strengths, the staff was
a set of good, journeyman programmers--no gurus, except for one
exceptional young woman--with anywhere from a few month's to 10 years
experience with Ada, the design was in keeping with a quality
methodology (OMT), and development followed a rigorous
"command-and-conquer" process for all defect
identification/analysis/resolution/rework/retest/rebaselining. And
yes, it was made certain that everyone rigorously followed it.
 
Reread what the outcome was:
 
>>mcq95:
>> The end result of the project was a serious weapon command and
control
>> system that came in on schedule, on budget, with no late nights or
>> weekends required of either the development or test staff, and the
>> lowest number of unresolved defects in any production release of
the
>> system--1 of severity 4 (out of 5, where 1 is critical, and 5 is
>> considered a nice-to-have).

We did all that stuff that you claim is supposed to work against
project success, yet the project succeeded nonetheless, and rather
painlessly at that.

> The only thing is they might privately grumble more, and may
> often have to get C/C++ libraries written by outside vendors
> or themselves.  (Usually there are excuses - We could
> have done it all in Ada, except for this and that...
 
Now where does that come from? "Grumbling?" "Excuses?" About going
home and having dinner with the family each night, and having one's
weekend to themselves?
 
Excuses for what? For the system having the lowest defect rate of any
production release and it steadily improving with each passing day?
Okay--it was Ada's fault!
 
There still seems to be this complete ignorance of the benefits of Ada
and strong typing: Strong typing doesn't just "catch errors" (but for
the sake of argument I'll allow the low figure of 2-3% that you
propose). Some such errors you don't even really notice as errors. For
instance, if I accidentally swap Latitude and Longitude in a procedure
call, the compiler barfs, I fix it, and move on. Well, that one
compilation error just saved a lot of time, since that error probably
wouldn't get noticed until an executable gets into some sort of
testing, whether unit or system testing.
 
But again, the real benefit of error prevention comes not from those
errors that are caught, but from those that _never_ occur!
 
Iterating over an array:
 
   for Eng in Engagements'Range loop
      ...
   end loop;
 
There will _never_ be an array indexing error.
 
Every reference to Some_Type'Last or Some_Array'Length will _always_
be valid, they will never, ever exceed the valid range.
 
When strong typing is properly employed,  a variable will never take
on an invalid value--and if an attempt is made to do that, such as by
assigning to a subtype with a more constrained range, an exception is
immediately raised (one of those 2-3% of errors).
 
It's not that Ada prevents all errors from occurring (that's an absurd
claim that anti-Ada zealots repeatedly and disingenuously try to
attribute to Ada advocates), but it a priori does in fact prevent
certain classes of errors from occurring, and immediately catches
other classes of errors when they occur. And these errors continue to
be put into code every day by programmers throughout the ability
continuum: idiot, competent, and guru.
 
It's no harder to code taking advantage of strong typing than not, and
thereby avoid whole classes of errors--and I'd argue it takes more
effort to fight it, or to manually code the equivalent capability in
more weakly typed languages.
 
Given the effort it saves, why not code in Ada?
 
Marc A. Criley