To: "INTERNET:seaint(--nospam--at)seaint.org" <seaint(--nospam--at)seaint.org>
Subject: RE: Complexity of Code
From: Peter Higgins <76573.2107(--nospam--at)compuserve.com>
Date: Wed, 7 Feb 2001 10:47:16 -0500
My apologies for the poor spelling. It was indeed intended to be
I believe we agree. The code is not static, and must progress to include
our increases in knowledge and experience. I certainly must grapple with
new topics and methods in the steel area, particularly with the
"promulgation" of LRFD.
The point is how it changes. The code is used by practitioners.
Accordingly, it should be written by practitioners, or at least a
preponderance of them within a collective authorship. Practitioners have
already been through the process you describe, and very often formulate
things in a manner more intelligible to the guy in the trenches. Some of
this "new stuff" in the code is certainly needed and important. However, it
does no one any good if the regulations are so arcane that competent
engineers spend numerous sleepless nights puzzling them out.
Practitioners also separate the "what" from the "how". This is sadly
lacking these days. The code should tell us what to do, not how to do it. A
lot of the problems we are having result from well intended efforts to turn
the code into a design handbook. Unfortunately, with a majority of non
practitioners of a committee, these design aids are usually of precious
little use to the everyday engineer and only serve to confuse.
The end result is excessive complexity. Maybe it's a good thing. If we
cannot figure it out, we must think for ourselves as you did, rather than
blindly follow some code formulation. However, it would be far better to
throw out all the hand holding verbiage currently in the code and stick to
the requirements without the "guidance". This alone would simplify things
Peter Higgins, SE