Re: Bad coding standards

[Lao Xiao Hai <laoxhai@ix.netcom.com>]

Has anyoe ever noticed that the people who no longer write code are often the
ones most compelled to make up rules for those who do?

IBM used to have a little monthly publication called THINK.   In a 1964 article
in THINK,  some writer, whose name is now lost in the obscure recesses of my
faltering synapses, wrote, "The last act of a dying organization is to enlarge the
rulebook."    I have witnessed this in action over the years.   For example, when
a company is in financial trouble, the Human Resources Department begins to
enforce a "dress code."

When we run out of ideas for new software products, we often allow an organization
to coagulate into a tangle of well-intentioned standards that serve to inhibit rather
than
stimulate creativity.   Then we set up a standards group that intimidates everyone
else
into a lock-step process that ensures nothing interesting will ever be accomplished.

I am not opposed to standards, per se.   However, I sometimes think that Bill Joy of
Sun
Microsystems is correct when he observes that those organizations that depend too
much
on standards often become less innovative and consequently, less competitive.   There
has
to be some happy medium between regulation and anarchy in the pursuit of effective
software practice.

Richard Riehle

Wes Groleau wrote:

> > There are people in the world who are "Control Freaks" or who demand that "The
> > Law Is The Law!" and you often have to be careful about how they are going to
> > look at what you write down. Style *should* be something that is consistent and
> > details help, but you also want a lot of leeway to wiggle if there are reasons
> > to do so. IMHO, a reliable and properly functioning piece of software that is
> > delivered on time is more important than a really pretty piece of software that
> > doesn't work right and/or is late. Strict adherence to style does not
> > necessarily move the mission forward.
>
> The problem is when allowing "wiggle room" results in
> difficult-to-read-and-maintain software because certain
> people will not apply common sense--it has to be applied
> by force from outside.
>
> Our solution: Move a few of the "guidelines" bullets in AQS
> into "standards" bullets.  Then define "standard" or "shall"
> as "non-compliance requires a waiver signed by _____" and
> define "guideline" or "should" as "non-compliance requires
> approval from a peer review team."
>
> We also significantly revised AQS.  Some things we didn't
> agree with, others we thought unclear, and it was surprising
> how many examples were non-compliant.  (Principle of technical
> writing--given an unambiguous requirement in prose and a
> non-binding example, if they disagree, the example will be followed.)
>
> --
> Wes Groleau
> http://freepages.rootsweb.com/~wgroleau