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

["Robert I. Eachus" <rieachus@attbi.com>]

soft-eng wrote:

> Other times are when the bug is very intermittent
> and cannot be duplicated and you have to proceed
> blindly, based on theories that are sometimes half-baked.

We call those Heisenbugs.  Converting a Heisenbug to a Bohrbug that you 
can reproduce is often the first part of fixing the problem.

> And then there are cases where you are working
> with a crucial part of the system, without fully
> understanding its full impact on the rest of the
> system.  So you fix a bug, and the rest of the
> system comes crashing down on you...
> 
> But the truth is the choice of language has little to
> do with situations like these.

No, no, NO!  Sorry. There are two nice software engineering terms 
coupling and cohesion. Low coupling means that program modules have a 
low degree of interaction with other modules. Cohesion means that code 
in one module all deals with the same data construct or constructs.  Low 
coupling and high cohesion are good, and the combination of good 
software design and Ada allows you to achieve very low coupling and good 
cohesion.  You can't manage this without good software engineering, and 
you can do bad software engineering in just about any progamming 
language, including Ada.  What Ada allows you to do is accomplish 
extremely low coupling.

For example, assume your design requires several different list 
structures, including single and double ended queues.  In Ada you can 
have a dozen different queue types in your program library.  At each 
point where a list or queue is needed you instantiate a generic.  The 
generic instantiation is the only coupling between the program and the 
queue module.  There is no coupling between the queue module and the 
program.

This combination of data hiding, data abstraction, and modularization is 
what makes Ada so wonderful for programming in the large.  In a good Ada 
design, it is normal for program modifications, whether they are bug 
fixes or adapting the system to new requirements to only affect one 
module.  I can't begin to count the number of times when something which 
would be a month's work if we hadn't used Ada turned out to be a 
"trivial fix" in Ada.

I remember one time when during the system acceptance testing for a 
150,000 LOC project, the users noticed a problem with the user interface 
(which worked as specified).  At the end of the first day, the program 
manager was tasked to find out the cost of making the change, which 
would require a change to several major data structures.  (Basically it 
provided a common mechanism for the users to back out of any data entry 
transaction with no updates occuring, rather than knowing how often to 
hit the escape key.)

By lunch the next day, he had a cost estimate, and a (one page) diff 
from re-running all the test scripts.  Turned out that the change 
belonged in a component which was part of all the data types, and the 
implementation was private to one package.  Total LOC changes?  Nine, 
including three comment lines. ;-)

> Sorry, there is NO magic bullet for such things.
> I strongly doubt stories where the choice
> of a new language turned all coders into
> highly disciplined professionals, just like
> I doubt array-bounds-checking is the most
> useful invention in programming languages ever,
> before which everybody was just sloppily writing
> outside their arrays all the time as a matter of habit.

Ada is not a magic bullet.  What it does allow is that if you have a 
good process for creating a workable overall software design structure, 
then Ada modularization rules match the project structure.  As long as 
the implementor of a module stays within the lines, he can't add 
coupling to the system during development.  To go back to the original 
discussion, once the software design is finished, any change which would 
increase coupling comes with very serious warning flags attached.

Since there is almost never a reason to make one of those changes, a 
project manager can keep a hammer in his office to use on anyone who 
proposes such a change.  (A foam rubber hammer, of course, unless you 
have some programmers who are incapable of learning. Actaully, this is a 
matter of personal preference.  At Stratus I kept a plastic Whiffleball 
bat in my umbrella stand, and it came out and was on my desk or in my 
hand whenever someone wanted to change a global data structure, in a way 
that was visible to other modules. ;-)  Sometimes finding a way to make 
the change without adding coupling is tough.  But in the long run it was 
worth it to take several hours of time to find a better way.