Blaming Ada

[tannend@source.asset.com (David M. Tannen)]

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.
>
>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.  

This is absolutely true.  I am now witnessing a project going through
integration nightmares all because there was no design.  Exactly one
year ago someone on this project showed a piece of their code - a 20
page spec.  Yes you read that right - 20 pages of Ada specification.  When
I pointed out that this is not how things should be done in Ada or 
software engineering or structured programming - I was informed that this
code was written by one of the departments best programmers.

I continued to point out that no senior engineer was watching the design 
(I was on a related project with a bit of free time).  Then I got busy
with my own project.  Now I am in the middle of this nightmare.  We have
been integrating this system for 5 months with no end in sight.  Oh the 
project is about 9kSLOC if anyone is interested.
>
>The morale of the story is that bad programmers can screw up using any
>language.  Ada just makes this more visible.

I agree with you Dave.  How do we make things better?  My forehead hurts
from beating it against my management brick wall.

>
>				dave

David Tannen
tannend@source.asset.com
-------------------------------------------------------------------------
-- "Dependence on wizardry to mitigate the fundamental limitations of 
--  software is called 'hacking'."  Grady Booch
-------------------------------------------------------------------------