--- In email@example.com
, Phlip <phlip2005@g...> wrote:
> With dozens of years and hundreds of coders, their code is probably
> very clean and readable. You couldn't stomp in a change for tomorrow's
> launch, but they all know that code clarity affects the bug rate, and
> they know to clean it up.
I worked on several such systems (in Ada, of course), and often saw
thoroughly polished, clearly written, well designed (and over-documented) code.
On my favorite process-heavy project we had a 3 to 1 ratio of verification engineers
to design engineers, and the review process was almost as good as pair
programming. A lot of informal pairing sprung up anyway, since everyone
was so afraid of submitting mistakes.
At one point we were organized into groups of about six, with a verification
engineer in charge of each group. That worked pretty well, but was dismantled
for stupid political reasons.
Even changes to the automated tests (which had damn near 100% code
coverage) had to be thoroughly reviewed and approved by a change-control
board like everything else. In this case we survived because the requirements
were relatively stable. It wasn't as good as Agile, but it was a better way to
build airplanes than Chaos.
I'm guessing cost per line of code was 20 times higher than the Java stuff
I'm doing now. I'd hate to imagine the cost (or even the feasibility) of