The ‘fuzz factor’ in engineering: when continuous improvement is neither
During my nearly 25-year career as an engineer, I've witnessed some 75 code and standard revision cycles representing thousands of pages of text requiring review and interpretation.
The biggest threat to human life in a building isn’t the potential of natural disasters, but the threat of human error. I believe it’s a reality that increases in probability every time a code or standard change is proposed.
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 snowstorms. As an engineer who has taken an oath to protect the public, that responsibility is paramount to me and one I carry with pride.
But the system we have set up to protect society 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.
Dubbed the “fuzz factor,” this trend of growing complexity and shrinking time is one I believe poses a very real threat to public safety.
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.
My solution: Have a peer engineer perform a simple cursory review of projects.
To make this fully effective, it should not just be one or two peers. It should be more like five 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.
Editor's Note: This is sponsored content. All text and images were provided by the sponsor company.