The “Fuzz Factor” in Engineering: When Continuous Improvement is Neither

Posted on September 23, 2013 by bzabcik

Sometimes, being an engineer makes want to put my finger through my eye, into my brain, and swish it around. Reading and interpreting code requirements is one of those times. I’m not that old (please let me live in bliss on that one) but in my almost 25 year career as an engineer, I have seen some 75 code and standard revision cycles representing thousands of pages of text to review and interpret for laymen who are cursed with having to make a living selling building materials in this brutal marketplace.

I know the purpose of building codes and standards is to protect the public who need protection from the very real threats of hurricanes, tornadoes, earthquakes and freak snow storms. As an engineer who has taken an oath to protect the public, that responsibility is paramount to me and is one I carry with pride, I guarantee it. But the system we have set up to protect society in this regard has grown beyond a manageable state into monster status. Moreover, it is a venue filled with hundreds of hyper-sensitive, over-reacting people with individual research and commercial agendas, ballooning paper and free-running ink. In a recent personally defining moment, I stepped away from the tree trunk pushed firmly against the end of my nose and decided to gander upon the whole forest. What I saw concerns me because of the responsibility I have to protect the public. You see, I’m beginning to believe that the biggest threat to human life in a building is not the possibility of natural disasters but instead the threat of simple human error that increases in probability every time we plant a tree in our precious forest of public duty by introducing a code or standard change proposal. The requirements in these documents are long and complex already and getting them applied correctly to a project in a reasonable amount of time while battling the constant barrage of phone calls, texts, and emails a feat worthy of the likes of Albert Einstein and Carl Fredrich Gauss. (If you’ve never heard of Gauss, I suggest you Google him. He was one of the greatest minds of all time.) It has been called by those who have ventured down this thought path before me as the “Fuzz Factor” and I believe it to be a very real threat to public safety in today’s engineering world.

Let’s start by looking where the rubber meets the road. In 1960, the AISI cold-formed steel specification had 22 pages of requirements. In 2007, it had 114.  The latest edition, 2012, has 150 pages. That’s a 680% increase in 52 years. Congratulations, AISI. You have the smallest growth rate of all the standards I track at a little under two pages a year. Hey, stop laughing at your thin-walled brother, AISC design specification because you should be ashamed. In 1941, you had 19 pages of requirements. Twenty years later, you had 57 pages.  Ten years after that, 157 pages. In the most recent edition, 2010, you’ve ballooned to 239 pages. That’s about 3 pages per year not including the seismic provisions. That little piece of work did not exist until 1992 at 59 pages and is now a fat 335 pages in length. Growth rate: a whopping 15 pages per year. That’s something akin to sumo wrestlers in training. It is no better on the load side of the equation, either. ASCE 7, the standard that establishes the load levels to be expected from environmental phenomena like snow, wind, earthquakes, etc., was 92 pages in the 1988 edition. The latest edition, released in 2010 is a sporty 368 pages. That’s a growth rate of 15 pages per year as well.

Now, let’s look where pencil meets paper. Ultimately, the problem manifests in the fact that people reading and applying the code provisions are human beings with all of the limitations bestowed upon us by our creator(s) or evolution, however you choose to view that. The question is: Have human minds grown in requisite ability to read and understand all of this information? Being that Gauss died in 1855 and there has not been another mathematician like him since then, I’d answer that question with a strong “no” and I’m not alone in that. There are quite a few educational psychologists who buy into the theory that we are actually getting less intelligent as time goes on, even though we are much better educated as a society, because education tends to stifle creative thought at an early age and that skill is not developed.

So, how do we address this trend of growing complexity and shrinking time? In my opinion, the answer is relatively simple. Instead of continuing to further define the problems and solutions like we’ve done so well in the last century, we need to consider evolving the engineering process to match the complexity level thrust upon the practitioners. Buildings don’t fail if the diaphragm resistance was wrong in the second significant digit because there was no torsion considered or because a column had second order effect that magnified its load by an unexpected 10%. Instead, they fail because the resistance was overstated or the load understated on a global level by 50% or more because that’s the level of conservancy in the code typically. Case in point: The 1983 Kansas City Hyatt disaster. The initial design by the engineer was a good one and likely would not have failed. It was a later revision to that design, one that gave it less than half of the capacity of the original, that ultimately caused the disaster. The proposed change came to the engineer at a time that they were busy working on something else and was not given proper consideration. A simple human error that any of us, no matter how smart we might be, are capable of.

To me, today’s environment is one where “can’t see the forest for the trees” problems flourish. Fortunately, those problems are fairly easily spotted when put in front of a person who is capable of seeing the forest because they don’t have an in-depth knowledge of the trees growing in it. In this case, that could be a peer engineer performing a simple cursory review. To make this fully effective, it should not just be one or two peers. It should be more like 5 or 10 people with widely varied experiences and preferably strong cultural diversity, each one spending an hour or so scanning the results of the design, rather than the design itself.  Diversity is more important than you might think because each of us brings to the table a unique set of skills but at the same time, we are all limited to our experiences. It’s the old adage that the oncologist will tend to suspect cancer and the dietitian will tend to cite nutritional problems with the same patient. So, let’s do what doctors do in this situation: Swallow our pride and ask for a consult from a practitioner whose experiences are different from our own. It’s simple, easy, and could save lives, let alone all of the trees consumed by the printing of fat building codes and standards.

Leave a Reply

Your email address will not be published. Required fields are marked *