The *ART* of Computer Programming

[Jim Harkins]

In article <12253 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
>In article <25eb63c7.6a42 at polyslo.CalPoly.EDU> jdudeck at polyslo.CalPoly.EDU (John R. Dudeck) writes:
>-The programming standards of an organization don't stifle creativity, at
>-least not the creativity of a disciplined craftsman, any more than they
>-would in say, a cabinet shop.
>
>Now, THAT depends on the standards.  It definitely is not true that ANY
>standard is better than none.  For example, DoD contracts call for really
>stupid deliverables, including documentation conforming to coding standards
>that a good, experienced software craftsman would not voluntarily obey.

I'll definately agree with that, the way things look now we'll have code like

/* increment counter */
i++;

And now they're talking about commenting standards! (the above is just the
coding standard.)  I can just picture changing that comment to "increment the
unsigned integer i being used as a counter while going through the array
of foos looking for bars".  If you look at the DoD's 2167 software development
spec you get the feeling that every rule in there is because not doing it
caused somebody somewhere a problem.  It's more of a CYA than anything
else, everybody can point to something in the pile of documents and say
"the standard says they'll do this, my job was to check it, they did it.
It's not my fault."

I think it's interesting that last November I posted a request for info
and/or advice on writing software under 2167.  In return I got absolutely
no advice but I was deluged in messages like "yeah, 2167 sucks" and "it's
unfortunate the military demands a methodology that is as outdated and
proven wrong as this one".


-- 
jim		jharkins at sagpd1

"I've found by and large that when the flu gets you, the best thing to do (other
 than go to bed, which is boring) is to go conquer something." -Jerry Pournelle