Re: ada-c++ productivity

[mfeldman@seas.gwu.edu (Michael Feldman)]

In article <jls.669954776@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes:
   ... stuff deleted ...
>>software Critical Design Review. It's likely that the software engineers
>>who inherit the code at transition will not be the same folks who had
>>the review/approval authority at CDR. The extensive 2167 documentation
>>will help close the familiarity gap.
>
>I agree that this is the theory, but, sadly, much of the 2167/A documentation
>I've been subjected to over the past several years has been essentially
>worthless for understanding the documented system. When this happens,
>the extensive documentation just makes a very expensive doorstop.

Hmmm. Deja vu all over again. 20 years ago I worked for a company that
required flowcharts and all sorts of other paper junk to be submitted
when programs were turned over to production. This was not a contractor,
the software was all internal stuff. The gatekeeper of the production
library had a little form with nice little boxes to check.

The flowcharts were usually generated, after the program was readied
for production, by Autoflow. Remember Autoflow? The program that produced
a 20-page flowchart on a line printer to document a 1-page Fortran
routine? Yeah, that's the one. That one little program killed a _lot_
of trees.

Unfortunately I never had the guts to test my theory that it didn't
matter if the flowchart matched a _different_ program. I can tell you for
sure that _nobody_ ever read the charts; they were useless. The only
things that really mattered were the record-layout diagrams, to show the
file structures. Unfortunately these almost never matched the code...

Don't flame at this fuzzy-headed academic for not understanding. I'm not
down on documentation, 2167A or otherwise, as long as it's useful.

Mike