Return to index: [Subject] [Thread] [Date] [Author]

RE: Complexity of Code

[Subject Prev][Subject Next][Thread Prev][Thread Next]
Then there is not disagreement. My argument was exactly as yours except that
I qualified my response to narrow the practitioner to one who is not only
familiar with the material but with the intended use (building type) that it
is to be used in. An engineer on the Seismology Committee who design tract
developments rarely has the same problems that face an engineer who design a
unique custom home. There is typically more creativity (at the expense of
the owner) in creative custom residences.
My point was that not only was the practitioner to have the understanding of
the limitations within the design (and the possibility of multiple changes
to the load path system over time), but that the quality of construction
becomes an issue that must be considered in the complexity of the code.
One quick example (I promise), a close friend and neighbor designed her
home - I provided the engineering. During construction, she used her
contacts to develop a team of framers who worked for a very large developer
in Southern California (I best not mention the name). The framers ignored
the specific structural details and choose to frame it similar to that which
they built daily for the tract developer. The City Inspector stopped the
project and called me to the site as well as the truss manufacturer.

The bottom line here was that the framers understood from building the same
model over and over again, what was to be done. However, when faced with a
new building type and details that were not familiar with their daily
practice, they were unable to evaluate the load path clearly shown in the
details and created some serious flaws.

There is an economics for construction of different sub-categories of
structures within the same general category. In other words, Residential
Construction is far too broad a classification to devise one type of
methodology. Simply stated, Multi-residential Apartments or Condos have less
chance that at some point in their future, a change will occur in the
lateral resisting system that will be significant. Single family tract
homes, will have a greater chance, but somewhat more restrictive due to
homeowner associations and community CC&R's. Custom homes (including custom
spec homes) have the greatest chance to be dramatically changed in the life
of the home. As I pointed out, we have yet to consider the complexities of
recreating the stiffness and lateral force resisting system on an existing
home designed to  the 97 UBC or later where original drawings and analysis
are not available - as is typically the case.

We are, I believe in total agreement as to the need of a practitioner to in
responsible charge of the creation of the code methods, however, we need to
be more specific so that the code writer understands the practical
application of the method and the resulting potential problems it can create
for future flexibility and change.


-----Original Message-----
From: Peter Higgins [mailto:76573.2107(--nospam--at)]
Sent: Wednesday, February 07, 2001 7:47 AM
To: INTERNET:seaint(--nospam--at)
Subject: RE: Complexity of Code


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