Need a book? Engineering books recommendations...

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

Re: ASCE 7-05 Errors

[Subject Prev][Subject Next][Thread Prev][Thread Next]
And after Houton Miflin pays for those proof readers, do they miss some
things?  You betcha.  Do they contact every single person who bought a
copy to give a new edition or errata.  Nope.

Your implication by your statements is that there is no proofreading done.
I can tell you that is NOT the case for the codes/standards that I have
been involved with (and it was EXTREMELY minor involvement...more like a
fly on the wall).

As to changes, I have no doubt that people would be willing to keep using
the same old thing no matter what.  Fact is that people don't like change.
But, like it or not, change is necessary.  And as Harold pointed out,
every proposed change in an ANSI standard (which each of the reference
standards are that make up the structural "code" by and large...i.e. NDS,
MSJC, ACI 318, ASCE 7, AISC Specs, etc) must have a reason for the change.
And "because I felt like changing it" is not an appropriate reason.  The
key thing that you said was something along the lines of "there did not
SEEM to be an urgent need for this change" (I added the emphasis).  If you
don't stick your head out of your office and into the code process, then
how do you really know whether what you perceive about the need for the
change is true or not?  How do you know that due to your personal
resistance to change, you are not just assuming that the change was not
needed?  When a contractor claims that you over-engineered something, does
that make him or her correct?  Or is it more likely that they made a
comment out of ignorance since they really don't know what it is that you
did or how you did it?  Could it be that the same might be true of you
with regard to code changes since you are too busy "making a living" to
find at least a little time to become involved and more aware?

Oh, and like you (and other engineers), I too am "busy making a living",
yet I still find time to be involved and more aware of the code
development process.  As Harold stated and as I have stated in the past,
you DO NOT need to spend huge amounts of time (or any money) in order to
be involved with the code process.  Being involved does not necessarily
mean attending the meetings or working long hours on the code.  Being
involved can be a simple as downloading the public comment documents for
changing standard, read through them, and offer up comments if warranted.
I can tell you that when I worked for ACI, that one particular cycle of
change for the MSCJ (masonry code) have something like only 3 public
comments on the proposed changes.  Even if you assume that only 1% of the
people downloading and reading the proposed changes found something to
comments about, then that is still only 300 people downloading and reading
the changes.  300 out of how many practicing engineers (and architects) in
this country?  That is a rather sad commentary on us if you ask me
considering all you had to do was download a document and spend maybe
serveral hours (if that) to maybe a couple days reading it (depending on
how detailed you reviewed).

Regards,

Scott
Adrian, MI


On Mon, 18 Jun 2007 ndz28(--nospam--at)aol.com wrote:

>
>
>
> This is an incredible dialogue!  If Houton Miflin (the largest publisher of school textbooks) publishes a new Calculus text because someone has decided that the old ones are outmoded and require updating, it's up to Houghton Miflin to MAKE DARN SURE that the textbooks they put out are correct.  Which means that Houghton Miflin pays for proofreaders. Period.  And the same goes for any new code.  No code book should ever be published before it is completely and painstakingly proofread, paid for by the company that will benefit economically from the published text. Period. If volunteers want to help proofread, fine.  But nothing should ever leave the publishhing house before it is mistake free.
>
> I don't recall any one saying that errors can be fixed easily.  In fact quite the opposite was said; exactly why more proofing and more time is required between code cycles.  If some one 'forced' you to give up your perfectly good car and made you drive a new, defective car (and forced is the key word), I am sure you'ld complain.  It's exactly the same with this code writing process!
>
>  I'm sorry but most engineers (at least the ones I know) are too busy working at making a living. Most of us do not have the time to volunteer for this code writing process, but many of us do volunteer our engineering services.  We did not ask for the change.  We are not the ones starting the code change process. So either there is more proofing, code developers are held to a higher standard, or more time is allowed between major codes.  And, as I said before, there did not seem to be an urgent need for this change.
>
> Andrew
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Scott Maxwell <smaxwell(--nospam--at)engin.umich.edu>
> To: seaint(--nospam--at)seaint.org
> Sent: Sun, 17 Jun 2007 6:28 pm
> Subject: RE: ASCE 7-05 Errors
>
>
>
> I don't disagree with the notion that there is "time" for them to be held
> o higher standard, but would beg to differ that there is "money" for them
> o be held to a higher standard.  Considering how many people whine about
> he costs of codes right now, I don't see too many people willing to pay
> ore for extra efforts to try to further reduce errors.
> I will also disagree that codes should not be compared to design
> ocuments.  While I will agree that they are not completely the same, the
> act remains that an error on a design document could result in loss or
> arm of human life just as easily as an error in a code.  Thus, to me,
> oth need to be held to similar standards with regards to errors.
> Please don't get me wrong.  I certainly believe that there are things that
> an be done to make the system better.  But, I do object to people that
> et "preachy" about the code development process, especially when the vast
> ajority have never participated, even if it is just being aware of public
> omment period and reviewing proposed changes.  It is extremely easy to
> it in the "cheap seats" and point out all the flaws and problems, but
> UCH more difficult to actually get your hands dirty and DO SOMETHING
> bout it.  If you are SO concerned about the errors and you are SO sure
> hat they can be fixed easily, then why not get involved and fix the
> rrors...if it is so easy?
> And before some people start with all the excuses about how all the people
> n the code committees are supported by their companies and those that
> on't participate cannot afford to do because they are sole-proprietors or
> heir companies will not fund their effort, I will point out that I
> articpate and no one but me pays for my participation.  I attend meetings
> nd pay my own way.  So, I know it can be done by the "common" engineer as
>  am not exactly rolling in $$$.
> Regards,
> Scott
> drian, MI
>
> n Sun, 17 Jun 2007, Mark Johnson wrote:
> > I have to agree, codes shouldn't be compared to design
>  documents.  They are much more important than that.  I
>  also have to believe there is the time and the money
>  for them to be held to a higher standard design
>  documents.
>
>  I once worked in a firm that implemented a 100% peer
>  review policy for all documents that left the office
>  after they issued a drawing for a concrete beam with
>  no reinforcing in it.  I was surprised at how many
>  mistakes still got through.  It's difficult not to
>  produce  documents with mistakes, but it's not ok.
>
>  two more cents,
>  Mark Johnson
>
>  ******* ****** ******* ******** ******* ******* ******* ***
>  *   Read list FAQ at: http://www.seaint.org/list_FAQ.asp
>  *
>  *   This email was sent to you via Structural Engineers
>  *   Association of Southern California (SEAOSC) server. To
>  *   subscribe (no fee) or UnSubscribe, please go to:
>  *
>  *   http://www.seaint.org/sealist1.asp
>  *
>  *   Questions to seaint-ad(--nospam--at)seaint.org. Remember, any email you
>  *   send to the list is public domain and may be re-posted
>  *   without your permission. Make sure you visit our web
>  *   site at: http://www.seaint.org
>  ******* ****** ****** ****** ******* ****** ****** ********
>
> ******* ****** ******* ******** ******* ******* ******* ***
>    Read list FAQ at: http://www.seaint.org/list_FAQ.asp
>
>    This email was sent to you via Structural Engineers
>    Association of Southern California (SEAOSC) server. To
>    subscribe (no fee) or UnSubscribe, please go to:
>
>    http://www.seaint.org/sealist1.asp
>
>    Questions to seaint-ad(--nospam--at)seaint.org. Remember, any email you
>    send to the list is public domain and may be re-posted
>    without your permission. Make sure you visit our web
>    site at: http://www.seaint.org
> ****** ****** ****** ****** ******* ****** ****** ********
>
>
> ________________________________________________________________________
> AOL now offers free email to everyone.  Find out more about what's free from AOL at AOL.com.
>

******* ****** ******* ******** ******* ******* ******* ***
*   Read list FAQ at: http://www.seaint.org/list_FAQ.asp
* 
*   This email was sent to you via Structural Engineers 
*   Association of Southern California (SEAOSC) server. To 
*   subscribe (no fee) or UnSubscribe, please go to:
*
*   http://www.seaint.org/sealist1.asp
*
*   Questions to seaint-ad(--nospam--at)seaint.org. Remember, any email you 
*   send to the list is public domain and may be re-posted 
*   without your permission. Make sure you visit our web 
*   site at: http://www.seaint.org 
******* ****** ****** ****** ******* ****** ****** ********