navigational complexity within building codes

University of VermontScholarWorks @ UVM

Graduate College Dissertations and Theses Dissertations and Theses

2017

Navigational Complexity Within Building CodesJames Stephen McLeanUniversity of Vermont

Follow this and additional works at: https://scholarworks.uvm.edu/graddis

Part of the Engineering Commons, and the Fine Arts Commons

This Dissertation is brought to you for free and open access by the Dissertations and Theses at ScholarWorks @ UVM. It has been accepted forinclusion in Graduate College Dissertations and Theses by an authorized administrator of ScholarWorks @ UVM. For more information, please [email protected].

Recommended CitationMcLean, James Stephen, "Navigational Complexity Within Building Codes" (2017). Graduate College Dissertations and Theses. 812.https://scholarworks.uvm.edu/graddis/812

https://scholarworks.uvm.edu?utm_source=scholarworks.uvm.edu%2Fgraddis%2F812&utm_medium=PDF&utm_campaign=PDFCoverPages

https://scholarworks.uvm.edu/graddis?utm_source=scholarworks.uvm.edu%2Fgraddis%2F812&utm_medium=PDF&utm_campaign=PDFCoverPages

https://scholarworks.uvm.edu/etds?utm_source=scholarworks.uvm.edu%2Fgraddis%2F812&utm_medium=PDF&utm_campaign=PDFCoverPages

https://scholarworks.uvm.edu/graddis?utm_source=scholarworks.uvm.edu%2Fgraddis%2F812&utm_medium=PDF&utm_campaign=PDFCoverPages

http://network.bepress.com/hgg/discipline/217?utm_source=scholarworks.uvm.edu%2Fgraddis%2F812&utm_medium=PDF&utm_campaign=PDFCoverPages

http://network.bepress.com/hgg/discipline/1141?utm_source=scholarworks.uvm.edu%2Fgraddis%2F812&utm_medium=PDF&utm_campaign=PDFCoverPages

https://scholarworks.uvm.edu/graddis/812?utm_source=scholarworks.uvm.edu%2Fgraddis%2F812&utm_medium=PDF&utm_campaign=PDFCoverPages

mailto:[email protected]

NAVIGATIONAL COMPLEXITY WITHIN BUILDING CODES

A Dissertation Presented

by

James S. McLean

to

The Faculty of the Graduate College

of

The University of Vermont

In Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy Specializing in Mechanical Engineering

October, 2017

Defense Date: August 2, 2017 Dissertation Examination Committee:

Dryver R. Huston, Ph.D., P.E., Advisor

David V. Rosowsky, Ph.D., P.E., Provost and Senior Vice President, Chairperson Douglas G. Fletcher, Ph.D. Eric M. Hernandez, Ph.D.

Cynthia J. Forehand, Ph.D., Dean of the Graduate College

ABSTRACT

The premise, that building codes have become too complex, has been discussed,

commented on, and documented by practicing engineers; however, prior to this research there was little scientific evidence that codes have increased in complexity over time. There are many aspects of building codes that are complicated, and this reflects a combination of the inherent complexity of building design and the dynamical processes that produce the codes. This research focuses on navigational complexity and specifically the aspects that can be quantified to demonstrate current codes are more complex than their predecessors. Navigational complexity is defined as the complexity created by document cross referencing and other unintended structural features of a code. A metric for quantifying navigational complexity has been developed based on estimates of time consumed by an engineer stepping and navigating through codes. The metric can be used to quantify navigational complexity within a given code and between different codes. Although it is unclear as to what extent navigational complexity contributes to the overall level of complexity within a code, this research affirms that navigational complexity has increased in various codes over the years and can be used to compare complexity between different codes.

The complexity of building codes has been shown to be increasing in several

commonly used codes, and it may be necessary to simplify some codes. Additionally, this research postulates that it is possible for codes to become too complex and that there may be instances where the cognitive limit of navigational complexity within any given code is exceeded. However, building codes are complex for several reasons, and attempting to make codes less complex is not trivial. Without a method to reduce complexity, the task of simplification may be impenetrable. The developed metric for navigational complexity has been coupled with graphical representations to identify areas where navigational complexity can be reduced and areas where it may be beyond the cognitive limit of code users. The combination of numerical data and graphical representations may provide additional significant advantages that are not yet realized. Measuring and understanding navigational complexity within any code opens up the possibility of mitigation through reorganization and developing better navigational tools for future editions.

ii

ACKNOWLEDGEMENTS

I would like to thank my advisor Professor Dryver Huston for allowing me to pursue

this topic. Although building codes are not outside the scope of mechanical

engineering, they are certainly not common place within academia. I believe this

project started with a simple question, “what do you know about codes?” However, it

manifested into a passion for building codes that extends to both understanding their

complexity and what can make them better.

I would also like to thank Julie, my wife, for allowing this endeavor to continue

for a long time. There have been many obstacles in the way of this research,

some self-induced, others not, but Julie has always been supportive.

iii

TABLE OF CONTENTS

Page

ACKNOWLEDGEMENTS ............................................................................................. ii

LIST OF TABLES ........................................................................................................ viii

LIST OF FIGURES ........................................................................................................ xi

CHAPTER 1: INTRODUCTION AND REVIEW OF LITERATURE ...........................1

1.1. Introduction ......................................................................................................... 1

1.1.2. Motivation ................................................................................................... 2

1.1.3. Building Codes............................................................................................ 2

1.2. Review of Literature ........................................................................................... 6

1.2.1. Academic Literature .................................................................................... 7

1.2.2. Professional Literature .............................................................................. 13

1.2.3. Comparison to the United States Tax Code .............................................. 15

1.2.4. Implications of Code Complexity ............................................................. 21

1.3. Summary of Findings ........................................................................................ 23

1.4. Plan of Dissertation ........................................................................................... 24

References................................................................................................................... 26

CHAPTER 2: QUANTIFICATION AND AFFIRMATION .........................................29

Abstract ....................................................................................................................... 29

2.1. Introduction ....................................................................................................... 29

2.2. Background ....................................................................................................... 32

iv

2.3. Root Causes and Implications ........................................................................... 34

2.4. Methodology ..................................................................................................... 36

2.4.1. Interconnectedness .................................................................................... 36

2.4.2. Exception(s) .............................................................................................. 42

2.5. Results and Discussions .................................................................................... 45

2.5.1. IBC ............................................................................................................ 45

2.5.2. NFPA 101 ................................................................................................. 46

2.5.3. ACI 318 ..................................................................................................... 48

2.5.4. Exceptions within the IBC ........................................................................ 52

2.6. Conclusion ........................................................................................................ 53

References................................................................................................................... 54

CHAPTER 3: REDUCING COMPLEXITY THROUGH GRAPHS ............................56

Abstract ....................................................................................................................... 56

3.1. Introduction ....................................................................................................... 56

3.2. Background ....................................................................................................... 59

3.2.1. Code/Provision Importance ...................................................................... 61

3.2.2. Graphical .................................................................................................. 64

3.3. Methodology ..................................................................................................... 68

3.3.1. Globally..................................................................................................... 69

3.3.2. Locally ...................................................................................................... 69

3.4 Results and Discussion ......................................................................................... 70

3.4.1. Globally..................................................................................................... 70

3.4.2. Locally ...................................................................................................... 76

3.5. Conclusion ........................................................................................................ 83

v

References................................................................................................................... 84

CHAPTER 4: A CASE STUDY OF ELEMENTARY SCHOOLS AND THE

ASSOCIATED FIRE ALARM SYSTEMS...........................................................85

Abstract ....................................................................................................................... 85

4.1. Introduction ....................................................................................................... 85

4.2. Background ....................................................................................................... 87

4.3. Methodology ..................................................................................................... 89

4.4. Results and Discussion ..................................................................................... 91

4.6. Conclusion ...................................................................................................... 111

References................................................................................................................. 113

CHAPTER 5: REACHING THE COGNITIVE LIMIT ...............................................114

Abstract ..................................................................................................................... 114

5.1. Introduction ..................................................................................................... 114

5.2. Background ..................................................................................................... 115

5.3. Methodology ................................................................................................... 118

5.4. Results and Discussions .................................................................................. 124

5.4.1. Numerical Results ................................................................................... 125

5.4.2. Graphical Results .................................................................................... 128

5.5. Conclusion ...................................................................................................... 134

References................................................................................................................. 135

vi

CHAPTER 6: ABANDONING OLD CODES .............................................................136

Abstract ..................................................................................................................... 136

6.1. Introduction ..................................................................................................... 136

6.2. Complexity ...................................................................................................... 138

6.2.1. Complexity of Provisions ....................................................................... 139

6.2.2. Complexity of Codes .............................................................................. 140

6.2.3. Complexity of the Network .................................................................... 141

6.3. Suggested Approaches .................................................................................... 142

6.4. Conclusion ...................................................................................................... 145

References................................................................................................................. 145

CHAPTER 7: SUMMARY AND OUTLOOK.............................................................147

7.1. Metric .............................................................................................................. 147

7.2. Numerical and Graphical Representations ...................................................... 147

7.3. The Cognitive Limit ........................................................................................ 148

7.4. Future Work .................................................................................................... 149

7.4.1. Code Development Process .................................................................... 153

7.4.2. Future Codes ........................................................................................... 154

References................................................................................................................. 155

Bibliography ............................................................................................................. 156

APPENDIX A: METRIC DEVELOPMENT ...............................................................161

APPENDIX B: SAMPLE GRAPHS - IBC CHAPTER 9 ............................................162

vii

APPENDIX C: SUPPORTING GRAPHS....................................................................166

viii

LIST OF TABLES

Table Page

Table 1: Comparison in growth between the Building Code (1955 Uniform

Building Code and 2015 International Building Code) and the United

States Tax Code .....................................................................................................18

Table 2: The five classifications of Interconnectedness .................................................38

Table 3: The five classes of Interconnectedness with the assigned weighting

scheme for each class. ............................................................................................41

Table 4: Comparing the number of interconnectedness occurrences in three

sections of the IBC in the 2003 and 2015 editions. ...............................................45

Table 5: Comparing the weighted number of interconnectedness occurrences

with the three sections of the IBC identified in Table 4 ........................................46

Table 6: Comparing number of Interconnectedness occurrences in NFPA 101

Chapter 7, 2012 and 2015 editions ........................................................................47

Table 7: Comparing the weighted number of Interconnectedness occurrences in

NFPA 101 Chapter 9, 2012 and 2015 editions ......................................................47

Table 8: Comparing number of Interconnectedness occurrences in NFPA 101

Chapter 9, 2012 and 2015 editions ........................................................................47

ix

Table 9: Comparing the weighted number of Interconnectedness occurrences in

NFPA 101 Chapter 9, 2012 and 2015 editions ......................................................48

Table 10: Comparing the weighted number of Interconnectedness occurrences

in the ACI-318 Chapter 5, 1971, 1995, 2005 and 2011 editions ...........................49

Table 11: Indicators of references and quantities in the 2011 and 2014 editions

of the ACI-318 .......................................................................................................51

Table 12: The number of Exceptions within four editions of the IBC ...........................53



Table 14: Ten selected NFPA Codes (and Standards) and associated references

limited to the ten selected. .....................................................................................71

Table 15: Cross reference type and number of occurrences- ..........................................77

Table 16: Reference type and number of occurrences within Section 903 .....................78



Table 18: Total weighted complexity of the "where required provisions" of the

2009 IBC with regards to fire alarm systems in Elementary Schools ...................98

Table 19: Total weighted complexity of the "where required provisions" of the

2015 IBC with regards to fire alarm systems in Elementary Schools .................102

Table 20: The number and type of references within selected ACI 318 sections .........125

x

Table 21: The number and type of references from selected sections of NFPA

101........................................................................................................................125

Table 22: The number and type of references within selected IBC sections ................125

Table 23: The selected codes provisions (ACI 318, NFPA 101, and the IBC) and

the type and quantity of cross references within them. ........................................127

xi

LIST OF FIGURES

Figure Page

Figure 1: The quantity of MDI based on the Reference section of the IBC and

NFPA 101 ..............................................................................................................39

Figure 2: Intended hierarchical structure of Chapter 5, 1971 Edition ACI-318

[8]. ..........................................................................................................................60

Figure 3: A graphical representation of intended structure along with SDI and

MDI added to Chapter 5, 1971 Edition ACI-318 [8] .............................................67

Figure 4: A graphical representation, including the weights from weighting

scheme added to Figure 3 ......................................................................................68

Figure 5: The number of References made within each of the selected NFPA

Documents. ............................................................................................................72

Figure 6: The Number of Times each Selected NFPA Document is Referenced ...........72

Figure 7: Code Importance - Combination of Incoming and Outgoing

References ..............................................................................................................73

Figure 8: Code Importance for all NFA documents (pre-2012) - Incoming

References vs Outgoing References ......................................................................75

Figure 9: Top Ten Important NFPA documents .............................................................75

Figure 10: A graphical representation of the hierarchical structure of sub-section

903.3.......................................................................................................................79

xii

Figure 11: A graphical representation of sub-Section 903.3 with hierarchical

structure and cross referenced provisions ..............................................................80

Figure 12: A graphical representation of sub-section 903.3 with cross references

combined to eliminate multiple occurrences .........................................................81

Figure 13: A graphical representation of sub-section 903.3 with all provisions,

cross references and weighting scheme .................................................................82

Figure 14: Graphical Representation of the Hierarchical Structure of the 1988

UBC with regards to fire alarm system requirements ............................................93


UBC with regards to fire alarm system requirements and the associated

cross references ......................................................................................................94


IBC with regards to fire alarm system requirements and the associated

cross references. .....................................................................................................97

Figure 17:Graphical Representation of the Hierarchical Structure of the 2015

IBC with regards to fire alarm system requirements and the associated

cross references ....................................................................................................101

Figure 18: A graph showing the increase in navigational complexity over the

past 60 years. ........................................................................................................103


IBC with additional compounding navigational complexity of NFPA 72 ..........107

Figure 20: 1980's Fire alarm system in an elementary school ......................................110

xiii

Figure 21: 2015 Fire alarm system in an elementary school ........................................110

Figure 22: Examples of successive cross references within and outside the

estimated cognitive limit of code users ................................................................119

Figure 23: A simplified graph of a successive cross reference within the ACI

318........................................................................................................................129

Figure 24: An example successive cross reference with IHS added from only

one reference ........................................................................................................131

Figure 25: An example with references added to sub-provisions of section 16.4 ........132

Figure 26: An example of the result of a modification the reference in order to

reduce overall complexity. ...................................................................................134

Figure A.1: The different types of codes, levels of engineers and the time

associated with the classifications of interconnectedness ....................................161

Figure B.2: Complete list of provisions within the IBC Chapter 9 ..............................162

Figure B.3: Complete intended hierarchical structure of the IBC Chapter 9 with

associated edges ...................................................................................................163

Figure B.4: Complete intended hierarchical structure of the IBC sub-section 903 ......164

Figure B.5: Complete intend hierarchical structure of the IBC sub-section 903

with all references. ...............................................................................................165

Figure C.6: Chapter 5 of the ACI 318 1995 edition. The graph is a

representation of the intended hierarchical structure. ..........................................166

xiv

Figure C.7: Chapter 5 of the ACI 318 1995 edition. The graph is a

representation of the intended hierarchical structure as well as the

references made within the Chapter to other sections of the Code and other

Codes....................................................................................................................167

Figure C.8: A representation of a code network. Colored dots represent codes. .........168

1

CHAPTER 1: INTRODUCTION AND REVIEW OF LITERATURE

1.1. Introduction

This dissertation researches complexity within building codes, specifically the

development and use of methods of quantifying navigational complexity, and the

application of these methods to determine the growth, extent, effect on code usage and

means to mitigate navigational complexity.

Using building codes to design or check a design for compliance is often not a

simple task, because building codes are complex. The complexity of building codes

and the features of building codes that make them complex are not well understood,

and the definition of complexity, the quality or state of being complex [1], essentially

mandates first defining or at least understanding the definition of complex. The

definition for complex within the Merriam-Webster is: “a whole made up of

complicated or interrelated parts [1].” Building codes can be shown to be made up of

complicated or interrelated parts without any scientific method; however, to remove the

subjectivity a quantitative measure is necessary. This research develops a quantitative

measure of navigational complexity, a specific aspect of complexity, by first

establishing the definition for navigational complexity and then uses the definition to

develop quantitative methods for measuring and controlling the complexity of building

codes.

1.1.1. Navigational Complexity

Building codes are written with a specific hierarchy, but navigating them from

beginning to end is all but simple. There is complexity within the hierarchical structure

of most codes that disturbs the natural navigational path. This complexity can

2

generally be called navigational complexity. Navigational complexity is defined as the

complexity created by document cross referencing, which can be referred to as

interconnectedness, as well as other unintended structural features of a code.

Interconnectedness arises when one code cross references another code or even a

different section within the same code. These interconnections link different codes

and/or sections of codes, which in turn, make navigating a code challenging because of

added disturbances in the natural hierarchical path of the code.

Although building codes are likely complex for other reasons, this research only

focuses on the single aspect of navigational complexity. Quantitatively it may be

possible to show that building codes are made up of complicated or interrelated parts

through several methods, but by focusing this research on navigational complexity, it is

believed that some subjectivity is removed and the context is manageably constrained.

1.1.2. Motivation

Understanding the interconnections of regulatory codes and standards is critical

to ensuring safety to both people and property. In order to create or develop the highest

engineering codes and standards, it is imperative to understand what makes them

complex and hard to use. Measuring and understanding navigational complexity opens

up the possibility of mitigation. Mitigation of the current navigational complexity

levels and future navigational complexity is of importance to code users and code

developers. Through the reorganization of the codes and development of better

navigation tools, it may be possible to make building codes easier to use.

1.1.3. Building Codes

3

Building codes are fundamental building blocks for every aspect of the built

environment. The issue however, is that the complexity level within codes has grown

to heights where some engineers believe they are now too complex. Although outliers

do exist, many engineers will attest to this idea and have shared grievances within

literature. Most of these grievances are with new codes in comparison to old codes,

while other grievances are with specific provisions within a code. However, little

research has been conducted on what makes building codes complex, specifically what

makes them hard to navigate, and why the level of complexity may have increased.

The focus of this research is to review issues of complexity identified within literature,

with a particular concentration on navigational complexity, with navigational

complexity being the complexity that makes reading, understanding and using a code

difficult.

Understanding how and when building codes formed is important, but its

importance to understanding complexity may be limited. The complexities that existed

previously have often compounded over the years, in addition to the newly added

complexities. Stubbs provides a brief outline on the genesis of some of the more

widely used codes [2]. With a title, The Widening Web of Codes and Standards, the

author makes it clear that codes are complex and are becoming more complex in the

1988 article. Although the article provides a brief background on code history, it is the

conclusion that is important: “The other major factor likely to influence the future

relationship of designers to building codes is microcomputers. Some codes already

have been programmed into self-contained software data bases, with various types of

key word and search functions. The potential for determining compliance, updating

4

editions, cross-checking and eliminating inconsistencies is great, and the increasingly

intricate spiderweb of codes may soon be untangled [2].”. With all due respect to the

author, the spiderweb of codes has not been untangled, even almost 30 years later and

this is confirmed by literature.

While not necessarily an indicator of increased complexity, building codes have

increased in size over recent years. This can be confirmed by simple inspection of their

thicknesses or by reviewing their table of contents. This should not be surprising, since

the building design process and construction of even the most simplified buildings is

not always straightforward. Additionally, advancements in building construction,

resulting from new technologies, materials and research have significantly broadened

the scope of most codes. Similarly, the code development process for most building

codes is just as complicated. Codes that were once developed by insurance companies

are now developed and maintained by organizations whose main functions may be the

development and promulgation of a specific code or codes. The process of developing

and maintaining these codes requires constant attention.

Codes have existed since early civilization and despite no evidence to prove that

these codes were not complex, it is safe to assume that they lacked complexity. The

following excerpt dating from over 2000 years ago in Hammurabi’s Laws is indicative

of that: “If a builder build a house for some one, and does not construct it properly, and

the house which he built fall in and kill its owner, then that builder shall be put to

death” [3]. This may be the first building code and it was a performance based code,

because the only requirement for the house was that it could not fall down. This

essentially allowed for any construction method. It would be ignorant to not

5

acknowledge the fact that construction tools and methods during Hammurabi’s time

were basic at best. However, more advanced structures were continually being erected

and houses continued to provide adequate shelter. Although the code may seem harsh

today it certainly did not stop people from advancing technologies. The line from The

Code of Hammurabi is typically mentioned to every engineer and architect during their

studies. There is much more to The Code of Hammurabi than this single line, but it is

very interesting that for literally thousands of years mankind has been dealing with

issues pertaining to the construction of buildings. What is most fascinating is that at

even the earliest stages of primitive construction two things were clear: the safety of

occupants and insufficient construction methods.

Although it may seem that a simple solution to fixing increased complexity

within building codes would be to revert back to a simplified version of codes, this is

hardly a solution or even a possibility. Instead, as Thompson notes, with regards to the

discussion about the code of Hammurabi, “While this system undoubtedly had its good

points, we must turn from it regretfully without further comment to those measures

which fit more nearly the governmental system under which we find ourselves today

[4].” Additionally, “While most people would agree that today’s cell phones are far

more complex than the rotary dial phones of 40 years ago, few would go back to the old

technology. Why? Because the benefits gained using the new technology are worth the

extra time and effort required to understand its intricacies [5].” In short, longing for old

codes will not fix the issues at hand. Therefore, understanding the complexity within

current codes is of particular interest. The issues with current building codes, such as,

inefficient design, excessive cost of use, hindrance of new technologies and errors in

6

use, may jeopardize the safety of the occupants within a newly constructed building.

These issues may be the result of unnecessary complexity within building codes and

understanding the complexity may be important to future building safety.

1.2. Review of Literature

The importance of some form of building code is discussed within literature and

does not appear to be questioned. The following statement provided by Thompson

holds true even 70 years later:

Experience has proved that government must act in protection of the

public to control the operations of the ignorant, the incompetent, and the

unscrupulous in the construction field. Fire, collapse, and other sources of

injury and even death traceable to imperfect construction occur frequently

enough to remind us that trouble can occur even when regulations are in

effect to prevent it. What could happen in the absence of such regulations,

or in the event of regulations so weakened that they become inadequate,

can readily be imagined [4].

Similarly, Vaughn and Turner take the same position, “Building codes address

many of a society’s most important concerns, including public health and safety, and

environmental protection [6].” The importance of building codes does not seem to be

questioned within the literature; however, a significant amount of literature and

research was discovered detailing the effects of complex codes and how they add to the

cost of construction. The caveat being, this said literature most nearly never identifies

what actually makes a code complex.

7

A literature review was conducted to determine if navigational complexity had

previously been discussed, with regards to building codes. No such mention was

found, and a literature review of building code complexity in general was undertaken.

This review was expanded to include complexity issues within the United States Tax

Code, because of the overwhelming evidence that it is overly complex. The reviewed

literature is separated into four distinct areas where possible: Academic Literature,

Professional Literature, Comparisons to the United States Tax Code, and the

Implications of Code Complexity. Although all of the research was of value, it is

important to differentiate the origins of literature, because the perspective of the writer

is noteworthy. Practicing engineers are often more concerned with the usability of a

code and often have less concern with why or how a particular provision came to be.

While research engineers, not using the code, but involved with development may be

concerned with the genesis of a provision.

1.2.1. Academic Literature

Building codes, as most engineers know them today, have existed for about a

hundred years. They appear to have had some issues from the inception, as noted in

1946, “…it may be said that the defects of building codes are well understood, that

constructive efforts are under way to correct them…[4].” Although there may have

been efforts to solve the defects of previous codes, they either were not corrected

before, new defects have been created, or a combination of both, because a consensus

of the literature indicates issues still exist. In all likelihood, the issues that existed in

previous code editions have compounded through the years, which may not be easily

8

addressed. Examples of issues within codes can be readily found within professional

literature. Some of these issues may have been addressed and/or corrected, but new

issues continually appear. To solve complexity within codes, it is probably best to start

with individual provisions that are considered complex, “...complexity of current codes

has resulted in increasingly garbled provisions that adversely affect ability of engineers

to properly design...[7],” and attempt to resolve those issues. Solving provisional

complexity, the complexity within provisions, may not be the complete solution, but

will likely reduce the number of issues, new and old.

Although the origins of the complexity do appear to be relatively vague, there is

more concise speculation on why codes are now complex: “codes are complex because

designers and checking engineers insist that they cover every eventuality [8],” “…codes

are immense and complex to accommodate the many desires of building owners and

designers [9],” and “…we need complex codes to cover the complex construction

environment in this country [10].” Covering every eventuality or desire does not

necessarily suggest that, “the Code is complex because it deals with or attempts to deal

with complex structures [11].” However, Siess also states, “I believe that the

complications and complexities of the Code are, in many cases, justified and, in some

cases, inevitable; but many of them are remediable [11].” It should be noted that both

of these articles were written over thirty years ago and the code they reference, the ACI

318, has been re-organized and the complexity has certainly increased.

Examples of engineers improperly using or misinterpreting codes does not

appear to be a new issue and have been discussed in literature prior. Pitt describes an

instance where, “…he and some equally experienced architects once carried out the

9

exercise of applying the regulations to a specific set of plans and they each, after some

time, produced a different interpretation of what was required…[12]”. These

incidences can likely be shown to occur in a variety of building codes, but often do not

specifically identify what within the provision is complex and contributing to the

discrepancies. In order to reduce complexity and/or eliminate issues, the specific

problems must be identified. This is not a simple task because not all provisions are the

same. For example, some require calculation, while others do not.

The concern over the ability of practicing engineers to implement provisions led

to the use of Trial by Design problems, which are a tool for assessing the ability of

engineers to implement code provisions [13]. This tool essentially confirms that certain

code provisions are too complex by testing the engineers and examining the results. In

this case, the results showed that more engineering experience produced better results,

but did not guarantee the correct solution [13]. It seems rather intuitive, that engineers

with additional experience are more likely to arrive at the correct answer, but this test

was conducted on problems that required calculations. Issues with code complexity do

not appear to be limited to provisions requiring calculations, because issues with

interpretation are also noted within literature. The issues may be in the form of the

wording within a provision or the overwhelming amount of information within the code

in general.

The idea of needing to improve codes appears to be universally agreed upon, as

stated by McConnaughey, “Most observers, including members of the building

community, would probably agree that building code regulations and the entire

regulatory process can be improved… [14].” This sentiment is found throughout

10

professional literature. However, if all provisional complexity was eliminated it

appears that complexity would still exist. This infers that building codes are complex

for multiple reasons. It is stated that complex codes are necessary ([9], [10], [11]), but

this is questionable. If complex codes are necessary, then it would seem that complex

provisions are necessary, but it has been deomonstrated that complex provisions can

lead to mistakes. As such, there must be some middle ground.

Of the reviewed literature, only a few provided suggestions on how to reduce

complexity; however, many of these suggestions are for particular provisions only.

Searer et al provides an example of this, “The author has attempted to provide

information and recommendations regarding four controversial code provisions that

add significant complexity to the code but do not necessarily provide value equal to that

added complexity [15].” Other literature providing suggestions discuss those codes that

have been modified heavily over the years, but continue to be plagued with grievances

within more recent literature. Bulleit suggests that building codes are like

communication systems and that there needs to be a balance between explicit and

implicit provisions [16]. This article broadly describes how to make codes better, but

introduces the idea of noise with regards to communication theory. Noise being things

added to the signal that were not intended [16]. The idea of noise is of particular

interest because it can be related to navigational complexity.

There is also a suggestion that to reduce complexity by separating codes into

complex and non-complex structures, “if we can define simple structures with

sufficient precision for administration by the building official, it should be a fairly easy

job to write a simple code for such structures, and another code for all the remaining

11

complex structures [11].” Similarly, Galvin notes that most building codes generally

subject existing buildings and specifically renovations of existing buildings to the same

requirements for new construction, instead of rehabilitation codes. Rehabilitation codes

being those codes specifically used in the rehabilitation of buildings, but without

rehabilitation codes the projects are imposed with unnecessary costs [17]. If codes are

already complex, then separating codes or creating new codes will likely ensure more

complexity is added to the overall building code network. This is not to say that new

codes are not necessary, or that old buildings are not important; however, moving

complexity should be done so with careful attention.

There is a significant, almost endless, amount of literature on engineering

disasters and engineering failures. Many of these disasters and failures do not have any

connection to building codes or any other code; however, some failures of buildings or

structures do have a connection to building codes. Although the connection of a

building code to a failure or disaster is not essential to this research, it is relevant.

Petroski discusses several engineering disasters, of which most were not the result of

the applicable building code. Additionally, Petroski states that building codes were

noted as one of the least significant factors in preventing disasters within the 1982

Congressional Hearing on structural failures within the United States [18].

Instances where a building code was inadequate and the code was the sole

reason for a failure may exist, but that is not particularly important to understanding

code complexity unless the reason for failure could be attributed to code complexity.

This is because there are many differences between code complexity, the lack of

following a code, and the lack of an adequate code, among other items. Instead, it is

12

more important to understand that any error resulting from code complexity can lead to

failure in the same manner. A simple comparison of some plausible situations helps

demonstrate that the cause of any specific failure can in itself can be complex.

Scenario 1

A contractor uses 2 inch screws to fasten the supports for a deck. The

deck subsequently fails, and it is determined that the contractor failed to

use the required 3 inch screws.

Scenario 2

A contractor uses 2 inch screws to fasten the supports for a deck. The

deck subsequently fails, and it is determined that the contractor failed to

use the required 3 inch screws. The contractor failed to understand the

table within the code that describes which size screws to use, because he

used teak wood, which was an exception that required a 150% increase in

screw length.

Scenario 3

A contractor builds a deck without a permit and the deck does not meet the

current building code. The deck subsequently fails, because it is used to

support a hot tub.

The simple comparison shows that there can be several items that contribute to

any one failure and literature generally concludes the same. However, it is Scenario 2

that is relevant to this research, because it presents a situation that can be attributed

directly to code complexity.

13

1.2.2. Professional Literature

As an important ancillary piece of this research, articles not necessarily research

oriented, but instead presented by practicing engineers have also been included to

affirm the stance that building codes are considered complex. Several short, forum

type articles, were reviewed from STRUCTURE Magazine. The articles, which were

written by practicing engineers, provide insight into some code complexity issues

currently facing the engineering profession.

In an article, Who Hijacked My Building Code?, Pierson questions and points

out examples of code provisions that have been added, which the author believes are

not necessary. The author contends that provisions not related to life safety and are

merely “great ideas”, such as heating, should be driven by the free market and not the

building code [19]. There is no direct mention of code complexity within the article,

but the author’s position that provisions exist within the code that are not necessary is

important. The importance lies in the fact that unnecessary structural features of a

code, intended or not, increases navigational complexity. An earlier article, Changing

Building Codes – Are They Really That Bad?, Pierson hints that complex codes are

good, because they result in higher pay [20], which is similar to the idea that codes are

a sign of professionalism and define a professional community [21]. At first glance, it

appears that Pierson believes that complex codes are good, but then takes exception to

the unnecessary provisions. This is likely taking his thoughts out of context; however,

the idea that some engineers may want complex codes to ensure continuation of work

does not seem far-fetched. If codes are written in a way that they encompass

14

everything needed to design a building, then simply reading the code and following it

would not require an engineer.

Within a two-part piece, How Code Complexity Harms Our Profession, Defriez

discusses the ASCE 7-10 with regards to how it contains complex provisions. The

ASCE 7-10 and the complexity within it has also been the subject of academic research

[22]. Defriez details how the complex provisions within the ASCE 7-10 increase the

chances of misinterpretation and error, and provides an example of a complex

provision. The author also highlights how an instructor made a mistake using the

example provision while presenting a webinar because of the complexity within the

provision [23],[24]. In a similar article, Pence states that most buildings do not need

complicated codes to be constructed safely [25]. If most buildings do not require

complicated provisions, then separate codes, one for complex structures and another for

non-complex structures may ease the burden of use on engineers, at least those dealing

with the majority of buildings. This separation of code may be worth further

investigation.

The issue of code cycle length is also discussed in the literature ([25],[20]). The

primary concern among practicing engineers is that the cycle, every three years, is too

quick. Although this is of significance in terms of the added complexity with each new

edition, the issue of longer code cycles is not particularly relevant to making codes less

complex. Deferring the addition of new complexity to, for example every five years,

does not change the fact more complexity is being added, and the cycle length does not

address current levels of complexity. However, longer code cycles would provide more

time for engineers to become familiar with each code and may provide the necessary

15

time to fully test the implications of new provisions. Knee-jerk provisions, which are

often quickly added as the result of an event, can be/are necessary in some instances,

but without a proper review they may be adding complexity unnecessarily. The issue

of code cycle length, although important, is also not discussed further.

1.2.3. Comparison to the United States Tax Code

Title 26 - Internal Revenue Code, otherwise known as the United States Tax

Code, is also considered too complex, and has been analyzed by practicing users,

providing a significant amount of anecdotal evidence. However, unlike most building

codes, it has been analyzed more scientifically in research articles, and the notion of

being too complex appears to be confirmed. By examining grievances with the Tax

Code discussed within academic literature, it may be possible to provide guidance

towards establishing the complexity of building codes. This evidence could potentially

provide the justification necessary to warrant an overhaul of major building codes.

However, the truth to the idea that evidence of complexity ensures changes will be

made is somewhat clouded, because proving a code is too complex and acting on it are

two drastically different things. The overhaul or re-organization of a code is no simple

task, which is why the Tax Code has not been overhauled and continues to become

more complex. Nevertheless, it is certainly more feasible to overhaul a building code

than the Tax Code. By comparing grievances, it may be possible to extrapolate what

might happen if a building code becomes too complex.

Three common aspects of codes are: development, application, and

enforcement. The development process is a contributing factor to the complexity of the

16

Tax code, but there are vast differences between the Tax Code and most building codes.

The primary differences are that most building codes are consensus based and are not

controlled by the federal government, while the tax code is not necessarily consensus

based and is tied to the federal government. Additionally, there are many facets of the

Tax code that are written in a manner which creates a gap between developer and user.

Although, this gap is not necessarily the same between building code developer and

code user because of the differences between the Tax and building code development

processes, some gap likely exists. It may be necessary to investigate further the

disconnect between code users and developers, but as Mathews states the issue may not

actually be that simple:

A Code is essentially the work of a Committee which can rarely be

enthusiastically unanimous. Any particular clause is a consensus opinion

drafted by an individual who is doing his best to express a breadth of

ideas with shades and emphases which, although not incompatible, are

also not conducive to clarity and precision. Loss of clarity and precision

in the work of an individual expressing his own ideas is much easier to

avoid than in the expression of consensus opinion [26].

The Tax Code is developed by Congress, and many officials have no

background in finances or accounting. Although, the possibility does exist that a

particular code committee is made up of entirely academics or research engineers,

which are not actually using the code in practice, that scenario seems unlikely.

Instead, Siess eludes to a more likely situation, “One advantage of a committee is that

there will nearly always be at least one member who does not understand and will ask

17

for an explanation. On the other hand, there will usually be at least one member who

can provide the explanation…[11].” Essentially meaning that when consensus forces a

particular code provision to be generalized, it likely creates some level of complexity.

This may be unavoidable in any consensus based code, but it important to demonstrate

the existence of code complexity in the eyes of codes users. There often seems to be a

disconnect between code users and those developing the codes, which is particularly

evident with the Tax Code. Similarly, this is evident in articles written by practicing

engineers, specifically highlighting the issues with building codes and specific

provisions, because regardless of why a provision is there it may be too complex.

Although the development process of the Tax Code can limit the ability to address

complexity, this is not the case for most building codes. It is important to understand

the primary differences, because the possibility of making a building code less complex

may be far greater than improving the Tax Code. The ability of code users to submit

comments and suggestions for changes to new code editions means that many issues

may be resolved in the cycle.

The two other aspects of codes, application and enforcement, are nearly

identical in most building codes and the Tax Code. Both codes are applied and

enforced by people who may or may not fully understand them. For example, with

regards to application, the average person likely does not fully understand the Tax Code

but may decide to file their own taxes, and similarly, a contractor may not fully

understand the Residential Building Code (IRC), but still builds a home. The same can

be said for enforcement, an IRS agent does not necessarily have to understand the tax

code and a code enforcement officer does not necessarily have to understand everything

18

within the IRC. It is both aspects, application and enforcement, that are significant

with regards to the complexity similarities, but also of significance is the size of codes,

which is directly related to both application and enforcement. As such, grievances with

implementation and enforcement related to complexity have been compared, and the

size/growth shown for reference.

The built environment has become increasingly more complicated in recent

years, but not just in the physical sense. The building codes that form the backbone of

how buildings are built today have increased in size and scope. Culminating through

the years with each new edition into what are the latest editions, and most codes are

now several orders of magnitude greater in size than their predecessors. The Tax Code

is much larger than nearly all building codes individually, and there is an almost an

infinite number of articles discussing the complexity of the Tax Code. Similar to

articles written by practicing engineers discussing building code complexity, one of the

most common themes in articles written by tax professionals is the size of their

respective code. The downloaded version of the current Title 26 – Internal Revenue

Code is 6549 pages [27]. This is in contrast to the downloaded 1954 edition containing

907 pages [28]. Although building codes have grown, the speed at which they have

grown is far less than the rate at which the Tax Code has grown. For example, Table 1

compares the increased page count of the 1955 Uniform Building Code to the current

International Building Code and the 1954 Tax Code to the 2016 Tax Code.

Table 1: Comparison in growth between the Building Code (1955 Uniform Building Code

and 2015 International Building Code) and the United States Tax Code

Code Page Count Percent Increase UBC 1955 384 -

19

IBC 2015 700 82 Tax Code 1954 907 - Tax Code 2016 6549 622

The size of any particular document does not necessarily signify complexity and

can depend on what is actually being compared. Mitchell provides an example of this

when comparing the size of humans to yeast and the DNA structure of both; because

humans are larger, but the DNA structure of yeast is more complex [29]. Although, the

the technical nature of taxes or buildings certainly implies some complexity will exist

in their respective codes, any comparisons on size alone should be made in general

terms only.

All codes, no matter the subject or use, are generally designed for the same

purpose: to create uniformity. Tax literature suggest the complexity of the Tax Code

hinders uniformity. Money Magazine conducted a study that asked 45 tax

professionals to prepare the tax return for the same person and got 45 different results

[30]. This clearly suggests that the Tax Code may be overly complex. This is similar

to the study conducted by presenting engineers several problems and comparing the

results (Trial Design Problems) [13]. The overall results from the Money Magazine

survey appear to be have much more variation, but were based on an entire tax return,

unlike the Trial Design Problems which examined a single provision.

The implications of non-uniform application are not always clear when it comes

to taxes and buildings. A building code may be designed to ensure all buildings

provide the necessary level of safety, which seems rather straightforward, but

uniformity can be relative. For example, not all buildings look the same and not all

20

people pay the same amount of taxes. It is suggested in literature that taxpayers often

forgo tax savings to avoid the hassle of completing complex forms [31]. This suggests

that code users may forgo better designs to avoid a complex provision that may save

money. In theory, there is a set of rules that applies to everyone or everything;

therefore, the rules are the same for everyone or everything, but are rarely applied

uniformly across the board because of slight variations. As with taxes, non-uniform

application of building codes can have drastic effects and can be hard to detect.

Although not paying the appropriate amount of taxes can be a financial burden on some

people, it is likely not going to harm them. The likelihood of a misinterpretation of a

building code leading to an injury may or may not be any more likely, however, the

consequences of either are not trivial.

Enforcement of any code can be challenging, and there can be a variety of

reasons for the challenges. The first might be the size of the code and the second might

be familiarity, but any reason is likely linked to the complexity of that code. Tax Code

literature suggests, “complicated rules also generate imperfect enforcement [32].” This

is rather intuitive; if a code is short and simple to understand, then enforcing it may not

be complicated. However, Tax Code literature also suggests that those charged with

enforcing the Tax Code consider it complex, “Few would disagree with the proposition

that the U.S. tax code is too complex – not even the IRS [29].”

Most people working in the built environment agree that building codes have

become overly complex, but there are some people that would say having a complex

code means job security [20]. However, the issues raised with regards to the

21

complexity of the Tax Code demonstrates that unless both parties applying and

enforcing a code can come to some agreement then there is likely too much complexity.

1.2.4. Implications of Code Complexity

The literature review indicates that the implications of code complexity have

been analyzed previously. A vast majority of the reviewed literature discusses

implications related to home construction in the 1950’s, but recent literature has also

highlighted implications more relevant to current issues, “Recently, however, some

interest in the economic and social consequences of building codes has been shown.

This due to the progressive proliferation of regulations and their perceived burden on

various actors involved in the building industry, and on society as a whole [33].” There

is significant importance in examining the implications of code complexity, because

errors in application or enforcement can be drastic. Unlike the implications of

complexity in the Tax Code, errors in the building code can result in life threatening

situations. Implications, such as cost, are easily understood and can easily be compared

to the Tax Code, but others are obscure.

The following excerpt is from a report on Massachusetts’ Building Code:

At least since 1970, the complexity of developing and enforcing the

building code and specialized codes has been acknowledged as a problem

resulting in the inaccurate application of building code. Errors during

design, design review, construction and inspection have a negative impact

on both the individuals who utilize the structures as well as those entities

that fund the development [34].

22

The report does not specifically give suggestions on how to reduce complexity;

rather, it just states that the code issues should be addressed. The report does also

mention that the code process itself is complex, “the existence of numerous specialized

codes and the number of agencies involved in developing and enforcing these codes

exacerbates the complexity of the code development and enforcement process” [34].

This statement suggests that the code development process itself adds complexity to

building codes. This was previously noted, “codes are complex because designers and

checking engineers insist that they cover every eventuality [8].” Although, confirming

the code development process is a contributing factor of complexity may be difficult, it

can likely be assumed.

Similarly, to the report on the Massachusetts Building Code, a report on

construction in New York City cites code complexity as an issue. The report does not

state how to make the code less complex, but does recommend changing to a Model

Building Code, which they feel is less complex [34]. An interesting issue raised in the

report is that of illegal activities due to code complexity, “In addition, the code’s

complexity leads to conflicts in interpretation, confusion and lengthy delays and

provides an opportunity for bribery and extortion” [34]. Extortion and bribery are

activities more typically associated with the Tax code and are always of concern, but

the fact they are considered to be a direct result of complex building codes is a unique

viewpoint that may require further investigation.

The “Building Code Burden” by Field and Rivkin is likely one of the most cited

pieces of literature with regards to building codes and the impact they have on costs.

That is the objective of the book, to show the impact of building code regulation on

23

home building [36]. The book provides example after example of why building codes

essentially hurt the free market, but does not have guidance on reducing the complexity

of using building codes, which is the focus of this research. Although the book

contains a substantial amount of important information, its value was only minor for

this research.

In a response to an earlier article written about the impacts of building codes on

housing cost, Martin makes an important observation, “… the sheer volume and

complexity of these technical standards often mask the fact that building codes and

code practices are as socially constructed as they are technically determined… [37].”

Building codes, as noted earlier, are consensus documents and certainly have more

influences than a technical report or trial-and-error testing. The code development

process may be flawed and may be the root of some complexity, but changing the

process will almost certainly not alleviate navigational complexity.

1.3. Summary of Findings

Examples of complexity are shown within literature, and most literature

suggests that codes are complex; however, these reports are largely anecdotal and

provide minimal quantitative data to back up these assertions. Quantifying the

complexity of codes may be the first step in justifying the need to reduce complexity,

because without hard data and metrics there is likely little motivation to change or to

confirm that a change has reduced complexity. Nevertheless, providing justification for

overhauling a code may not be all things necessary to actually overhaul that code. This

is evident with the current Tax Code, which has been proven to be overly complex, but

24

has continued to grow in complexity at an alarming rate. However, building codes are

developed in a different process, and they do not take an Act of Congress to be

overhauled. Although undertaking a major code overhaul is no simple task, it is

certainly more feasible. Most codes have not undergone fundamental changes over the

years and rightfully so, because most grievances with the codes are, and have been,

anecdotal at best. This literature review has also shown that some of the items that

make the current Tax Code overly complex are also found within current building

codes, and it can be inferred that if the Tax Code requires an overhaul then building

codes also likely to require an overhaul. With building code complexity increasing,

materials changing and improving, and practices being continuously updated, code

complexity is only going to increase if something does not change.

1.4. Plan of Dissertation

The dissertation can generally be considered three pieces: the development of

the metric, using the metric, and investigating the cognitive limit for navigational

complexity. A general summary of each chapter is provided below.

Chapter 2: Quantification and Affirmation

This chapter presents the first part of a two-piece submitted journal article that

both discusses the development of a metric for quantifying navigational complexity,

application of this metric affirming, what many engineers already believe, that building

codes have increased in complexity over the years. The results are presented

numerically for several commonly used building codes.

Chapter 3: Reducing Complexity Through Graphs

25

This chapter presents the second part of the two-piece submitted journal article

and expands the use of the metric to include graphical representations. By utilizing a

combination of numerical results and graphical representations, it is possible to

demonstrate that certain codes and even single provisions can have significant

importance with regards to complexity. The results presented indicate that it may be

possible to reduce complexity.

Chapter 4: A Case Study of Elementary Schools and the Associated Fire

Alarm Systems

This chapter presents a review of the requirements for fire alarm systems within

elementary schools over the past 60 years. This review specifically examines the

increased navigational complexity associated with the “where required provisions”

within the Uniform Building Code and the International Building. Also included is are

the details of how compounding navigational complexity can occur through referenced

codes.

Chapter 5: Reaching the Cognitive Limit

This chapter presents a journal article intended for submission that is a study on

the cognitive limit of successive cross references within commonly used building

codes. The study compares the complexity of wayfinding, with regards to

transportation, to navigating through a building code. The results suggest that there are

instances of complexity within current building codes that are likely exceeding the

cognitive limit of code users.

Chapter 6: Abandoning Old Building Codes

26

This chapter presents an article intended for submission within a journal forum.

The chapter outlines some of the major issues with current codes, with regards to the

ability to use them within Automated Code Checking software, and provides suggested

approaches on how it may be possible to create a building code that can be used to

completely auto check a design.

Chapter 7: Summary and Outlook

This chapter summarizes the major findings of this thesis, while also presenting

several areas of interest for future work.

References

1. Merriam-Webster.com. Merriam-Webster, 2011. Web. 31 August 2017.

2. Stubbs, M. Stephanie "The Widening Web of Codes and Standards." Doors and Hardware (1988).

3. King, Leonard William. The code of Hammurabi. Netlancers Inc, 2014.

4. Thompson, George N. "Problem of Building Code Improvement, The." Law & Contemp. Probs. 12 (1947): 95.

5. Poston, Randall W., and Charles W. Dolan. "Reorganizing ACI 318." Concrete international 30.7 (2008): 43-47.

6. Vaughan, Ellen, and Jim Turner. "The value and impact of building codes." Environmental and Energy Study Institute White Paper (2013).

7. Searer, G., et all. 2007. “Are we really learning from Earthquakes? Declining Quality and Increasing Complexity of Modern Building Codes”. In Proceedings of the 9th Canadian Conference on Earthquake Engineering. Ottawa, Canada, June, 2007.

8. MacGregor, J. G. "A Simple Code-Dream or Possibility?." Special Publication72 (1981): 199-218.

9. Scott, J. G. (1997). Architectural building codes: A graphic reference. New York: Van Nostrand Reinhold.

27

10. Wight, James. Email to the Author, October 2, 2013.

11. Siess, Chester P. “The 1971 ACI Building Code Too complicated, too complex or both?” ACI Journal (1974)

12. Pitt, P. H. "Towards a simplified code of building control." The Journal of the Royal Society for the Promotion of Health 99.1 (1979): 3-7.

13. Wilcox, C., B. Nuttall, and T. Barnett. "Connection Details—Practicing Engineers and the Code." 2011 Structures Congress. 2011.

14. McConnaughey, John S. An economic analysis of building code impacts: a suggested approach. Washington, DC: US Department of Commerce, National Bureau of Standards, 1978.

15. Searer, Gary R. "Poorly worded, ill‐conceived, and unnecessary code provisions." The Structural Design of Tall and Special Buildings 15.5 (2006): 533-546.

16. Bulleit, William M. "Structural building codes and communication systems." Practice Periodical on Structural Design and Construction 17.4 (2012): 147-151.

17. Galvan, Sara C. "Rehabilitating rehab through state building codes." The Yale Law Journal (2006): 1744-1781.

18. Petroski, Henry. To engineer is human. New York: St. Martin's Press, 1985.

19. Pierson, D., “Who Hijacked My Building Code?”, Structure Magazine, (April, 2016): 66.

20. Pierson, D., “Changing Building Codes – Are They Really That Bad?”, Structure Magazine, (May, 2013): 58.

21. Shapiro, Stuart. "Degrees of freedom: the interaction of standards of practice and engineering judgment." Science, technology, & human values 22.3 (1997): 286-316.

22. Morgan, Jessica L. "Have wind design provisions become too complicated? a look at the progression of design provisions for mid-rise buildings." (2009).

23. DeFriez, C., “How Code Complexity Harms Our Profession”, Structure Magazine, (July, 2014): 50.

24. DeFriez, C., “How Code Complexity Harms Our Profession, Part 2”, Structure Magazine, (Sept., 2014): 74.

25. Pence, E., “Code Complexity and Information Overload”, Structure Magazine, (Oct. 2006): 7.

28

26. Mathews, D. D. "Towards a European Code for Concrete–Can Concise Codes be Comprehensible and Comprehensive?." The Structural Engineer 54.12 (1976): 476-477.

27. Title 26 – Internal Revenue Code (2016)

28. Title 26 – Internal Revenue Code (1954)

29. Mitchell, Melanie. Complexity: A guided tour. Oxford University Press, 2009.

30. Laffer, Arthur B., Wayne H. Winegarden, and John Childs. "The economic burden caused by tax code complexity." Austin: The Laffer Center, Texas Public Policy Foundation. Available online: http://www. laffercenter. com/2011/04/the-economic-burden-caused-by-tax-code-complexity (2011).

31. Benzarti, Youssef. "How taxing is tax filing? Leaving money on the table because of hassle costs." Browser Download This Paper (2015).

32. Krause, Kate. "Tax complexity: Problem or Opportunity?." Public Finance Review 28.5 (2000): 395-414.

33. Arlani, A. G., and A. S. Rakhra. "Building code assessment framework." Construction Management and Economics 6.2 (1988): 117-131.

34. Deschamps, Denise, Building Code Development and Enforcement: Impact on Accessibility for Persons with Disabilities, 2010.

35. Salama, Jerry J., Michael H. Schill, and Martha E. Stark. Reducing the Cost of New Housing Construction in New York City. New York University School of Law, Center for Real Estate and Urban Policy, 1999

36. Field, Charles G., and Steven R. Rivkin. The building code burden. Lexington Books, 1975.

37. Martín, Carlos. "Response to" Building Codes and Housing" by David Listokin and David B. Hattis." Cityscape (2005): 253-259..

29

CHAPTER 2: QUANTIFICATION AND AFFIRMATION

Abstract

The premise, that building codes have become too complex, has been discussed,

commented on, and documented by practicing engineers; however, there is little

quantitative evidence that codes are more complex today than in previous editions.

There are many aspects of building codes that are complicated, and this reflects a

combination of the inherent complexity of building design and the dynamical processes

that produce the codes. This research focuses on navigational complexity and

specifically the aspects that can be quantified to demonstrate current codes are more

complex than their predecessors. Navigational complexity is defined as the complexity

created by document cross referencing and other unintended structural features of a

code. A metric for quantifying navigational complexity has been developed. The

metric can quantify navigational complexity within a given code and between different

codes. Although it is unclear as to what extent navigational complexity contributes to

the overall level of complexity within a code, this research quantitatively affirms that

navigational complexity has increased in various codes over the years and can be used

to compare complexity between different codes.

2.1. Introduction

Building codes have existed for thousands of years, and it is safe to state that

they are necessary. The importance of some form of building code is discussed within

literature,

30

Experience has proved that government must act in protection of the

public to control the operations of the ignorant, the incompetent, and the

unscrupulous in the construction field. Fire, collapse, and other sources of

injury and even death traceable to imperfect construction occur frequently

enough to remind us that trouble can occur even when regulations are in

effect to prevent it. What could happen in the absence of such regulations,

or in the event of regulations so weakened that they become inadequate,

can readily be imagined [1].

The statement holds true even 70 years later. Similarly, Vaughn and Turner

take the same position, “Building codes address many of a society’s most important

concerns, including public health and safety, and environmental protection [2].” The

importance of building codes does not seem to be questioned within the literature;

however, a significant amount of literature and research was discovered detailing the

effects of complex codes and how they add to the cost of construction. The caveat

being, this said literature most nearly never identifies what actually makes a code

complex, or provides quantitative measures of code complexity.

Building codes are written with a specific hierarchy, but navigating them from

beginning to end is anything but simple. There is complexity within the intended

hierarchical structure (IHS) of most codes that disturbs a natural navigational path.

Navigational complexity is defined as the complexity created by document cross

referencing and other unintended structural features of a code. Document cross

references, which form interconnections between codes and between provisions within

the same code, create navigational complexity. This class of navigational complexity

31

can be referred to as the interconnectedness of a code. Although all aspects of

navigational complexity affect the natural path, this research is primarily focused on

cross references. The other unintended structural features, such as exceptions, tables

and figures also disturb the natural path of a code user, but are not as quantifiable.

However, the extensiveness of exceptions within codes is significant and can also be

shown to have increased in recent editions.

The issue is that the complexity level within codes has grown to heights where

some engineers believe they are now too complex. Issues that existed in previous code

editions appear to have compounded through the years, which may not be easily

addressed. There is a correlation between the increasing complexity of codes and the

increased number of codes developed/added over the years. This can easily be shown

by examining the reference section of any code. As new codes or standards are created

they are inevitably referenced by current codes. This in turn not only increases the

number of referenced documents but also certainly the number of provisional

references within the code. Whether or not the dramatically increased number of codes

is a function of necessity resulting from new technology or societal influence, is likely

a debatable topic.

The basis for Chapter 2 of this research is twofold: 1) develop a metric for

quantifying navigational complexity and 2) use the metric to evaluate the degree to

which navigational complexity within commonly used building codes has increased.

The premise of this research is based on the idea that building codes are, in general,

complex. However, it may be necessary to demonstrate quantitatively that any given

code, has increased in complexity to warrant the need for reducing complexity, and as

32

such, it is imperative to demonstrate increased navigational complexity within various

building codes. Although, simply stating a code is complex or providing an example of

increasing complexity may be considered proof an entire code is complex, a more

detailed measure of complexity is likely needed as evidence. Evidence of navigational

complexity, through the use of the developed metric, can be found by showing the

interconnections within and between several commonly used codes.

2.2. Background

The concept of navigational complexity stems from a combination of the

authors’ experience using building codes and previous research studies. Almost

everything in the built environment being constructed today is built with respect to a

code or standard. This does not mean that everything being constructed is code

compliant or everything built today will meet tomorrow’s standards, but in general

most structures are compliant with the applicable code. Whether it is the smallest nut

and bolt or the number of parking spaces necessary to serve a building, there is a code

for it. Building codes are probably the biggest piece of the built environment puzzle,

because they drive, or at least restrict, almost every aspect of the industry. Building

codes, design codes and design standards, all can be loosely grouped under the single

term, building codes, and are all generally the minimum requirements for something

constructed. These requirements are for almost all structures used by the public or a

facet of some process that serves the public. Typically, the built environment is

considered to be buildings and other man-made surroundings, but it can be extended to

include items within the building and certain processes taking place within a building.

33

A literature review was conducted to determine if navigational complexity had

previously been discussed, with regards to building codes. No such mention was

found, and of the literature reviewed, that discusses code complexity in general, only a

small subset has been identified, which addresses how/why codes are complex. This

subset of literature referring to code complexity can be traced to articles or references

to articles prior to the 1930’s, from multiple countries. This is significant, because

many engineers will attest to the idea that codes are complex and have shared

grievances within professional literature. Many of these grievances are with new codes

in comparison to old codes, as stated by MacGregor: “The ACI Building Code has

become more and more complex as engineers and plan checkers have insisted that

every eventuality be covered in the code [3]”. Other grievances are with specific

provisions within a code as stated by Searer: “A primary concern among engineering

practitioners is that building codes are rapidly becoming too complex or confusing -- so

much so that some provisions are unworkable or unintelligible [5]”. However, there is

little documentation on code complexity and specifically the ways to make them easier

to use.

In a more recent forum article comparing structural codes to communication

systems the idea of, “noise” (i.e. things added to the signal that were not intended by

the information source) is introduced [4]. The idea of noise can be directly related to

cross references and other unintended structural features of a code. It is suggested that

reducing noise will make better codes [4], which can be directly related to reducing

navigational complexity to make better codes. This article is a slight variation from

many other pieces of professional literature, because most highlight issues with the

34

complexity of certain provisions within codes and do not broadly describe how to make

codes better.

2.3. Root Causes and Implications

The root cause of navigational complexity may be traced to previous editions of

codes, but there may be little benefit in examining old codes themselves. Instead as

Thompson notes, with regards to the discussion about the code of Hammurabi, “While

this system undoubtedly had its good points, we must turn from it regretfully without

further comment to those measures which fit more nearly the governmental system

under which we find ourselves today [1].” In short, longing for old codes will not fix

the issues at hand. This is a noteworthy statement in terms of the complexity of codes,

in the sense that understanding the root cause within a previous code edition may only

be beneficial if it can be used to reduce future complexity; otherwise, examining old

codes provides no tangible benefit. However, examining any code is essentially

examining an old code, because most codes are constantly in flux. The issue of code

cycle length is discussed within professional literature and may contribute complexity

through the development process. However, extending code cycles would not address

current levels of complexity.

In some instances, understanding the root cause(s) to an issue is the first step in

solving that issue, but there are other times when the root causes no longer matter.

Understanding the root causes of interconnectedness may be beneficial; however, there

are many reasons why codes become interconnected. This suggests that it is more

imperative to understand the basis for the individual interconnections, rather than the

35

history of why they are there. Nevertheless, a few rather simple explanations for the

root causes of interconnectedness are highlighted from literature. The first excerpt

outlines the importance and primary root cause of interconnectedness.

Now assume that a particular building code entitled the Y building code

were to reference the Accessible Design Standard X under the Y Code's

chapter regulating design for people with disabilities. This Y code would

be much greater in scope than the X Standard, as accessibility would be

only one of the concerns of the Y code. The Y Code would also regulate

the many fire safety, health safety, and structural safety concerns that are

not related to accessibility. Many other standards would be referenced by

the Y code and even other codes could be referenced by the Y Code. The Y

Building Code, in its adoptions by many different communities would help

promote more consistent and higher quality design throughout a large

geographical area [7].

This excerpt shows that interconnections are often necessary to ensure adequate

safety, but fails to address how the use of cross references can increase navigational

complexity. Additionally, another root cause of interconnectedness is the code

development process itself. Mathews sums up the process:

“A Code is essentially the work of a Committee which can rarely be

enthusiastically unanimous. Any particular clause is a consensus opinion

drafted by an individual who is doing his best to express a breadth of

ideas with shades and emphases which, although not incompatible, are

also not conducive to clarity and precision. Loss of clarity and precision

36

in the work of an individual expressing his own ideas is much easier to

avoid than in the expression of consensus opinion [6].”

What Mathews states is that provisions within codes are complex because of the

complex process to create them. Again, this root cause does not provide insight into

what can be done with the complexity already existing in current codes, but it can be

inferred that some cross referencing may be attributed to the lack of consensus.

2.4. Methodology

2.4.1. Interconnectedness

The interconnectedness of any code can generally be classified in one of two

categories: Multiple Document Interconnectedness (MDI) and Single Document

Interconnectedness (SDI). MDI can be considered a macro-type scale, as it can

encompass a wide range of codes; while SDI can be considered a micro scale, because

it only focuses on a single code. The implications of both forms of interconnectedness

are not yet completely known, but research has indicated that either category can

greatly contribute to the complexity of a code.

MDI is an interconnection created by a reference from a provision of one code

to a completely separate code. An Example of a MDI interconnection from the 2015

International Building Code (IBC) is shown:

904.3.5 Monitoring

Where a building fire alarm system is installed, automatic fire-

extinguishing systems shall be monitored by the building fire alarm system

in accordance with NFPA 72[8].

37

In general, MDI interconnections can be found by simply inspecting the

reference section of any code. The reference section of most codes lists the codes that

have been referenced within. In the simplest terms, the reference section can be the

basis for determining how much MDI complexity is within a code. However, the

number of instances and/or the specificity of individual references must be known, and

cannot be determined by inspection of the reference section alone.

SDI is an interconnection created by a reference from one provision to another

chapter, section or provision within the same code. An example of a SDI

interconnection from the 2015 IBC is shown:

904.3.4 Alarms and Warning Signs

Where alarms are required to indicate the operation of automatic fire-

extinguishing systems, distinctive audible and visible alarms and warning

signs shall be provided to warn of pending agent discharge. Where

exposure to automatic-extinguishing agents poses a hazard to persons and

a delay is required to ensure the evacuation of occupants before agent

discharge, a separate warning signal shall be provided to alert occupants

once agent discharge has begun. Audible signals shall be in accordance

with Section 907.5.2 [8].

Regardless of whether an interconnection is SDI or MDI, once the distinction is

made, it becomes apparent that they both can contribute different levels of complexity

depending on the specificity of the reference. This generates the need for quantifying

or at least capturing the different levels of complexity of both SDI and MDI

numerically. Table 2 list the five classifications of interconnectedness and the Intended

38

Hierarchical Structure (IHS). Although the IHS is not a separate type

interconnectedness it is part of the structure that contains the different types of

interconnectedness and must be differentiated.

Table 2: The five classifications of Interconnectedness

Single Document Interconnectedness IHS Intended Hierarchical Structure SDI-1 Provision A refers to another provision within Code

A SDI-2 Provision A refers to another chapter within Code

A Multiple Document Interconnectedness MDI-1 Provision A refers to a provision of Code B MDI-2 Provision A refers to a chapter of Code B MDI-3 Provision A refers to Code B

The first method of quantifying navigational complexity consists of examining

the reference section of a given code. It is the simplest way of proving an increase of

navigational complexity from one edition to the next, and it can also be used to

compare the MDI between two different codes, as shown in Figure 1. However, using

the first method for proving an increase in navigational complexity is not necessarily a

robust measure and provides limited information. Examination of the reference section

is useful in that it essentially proves the existence of navigational complexity, because

it confirms MDI exists within the respective code.

39

Figure 1: The quantity of MDI based on the Reference section of the IBC and NFPA 101

The reference section may be used to compare the number of references that

have been added or deleted from edition to edition, but beyond that, its use in

quantifying navigational complexity is incomplete. Additionally, documents like the

ACI 318, previous to the 2014 edition, provided references to all materials, which

included commentary, making it hard to quantify the number of references in the actual

code language. Due to the inadequacy of the first method, it is not used any further.

The second method of quantifying navigational complexity consists of counting

the number of references within particular pieces of codes. This method provides the

ability to compare chapters, sections and even entire codes when combined, not only to

one another but to previous editions as well. The second method is far superior to the

first method because it can capture all navigational complexity. However, it is limited

in that it quantifies all complexity the same, which has been shown previously to be

inappropriate.

40

The third method is the basis for the developed metric for quantifying

navigational complexity. It is an extension of the second method, because in addition

to counting all instances of cross references it also incorporates the different levels of

associated navigational complexity by assigning weights to the different types of

interconnections, but again the IHS is included with a weight of zero because in theory

it does not increase navigational complexity Table 3 lists a proposed weighting scheme

for the different classifications of interconnectedness. The weights correspond to the

potential for inducing complexity. The weighting values assigned to each type of

interconnection are derived from the author’s experience with using building codes and

experience witnessing other engineers use building codes.

The weighting values were formulated by considering the two primary types of

code use, electronic and paper, and three experience levels of engineers, new, mid and

senior. Included within the subset of new engineers is also the idea that it is possible to

use a new code, which regardless of experience is likely unfamiliar. Based on the type

of code use and experience level of engineers the time to move between cross

references and Intended Hierarchical Structure was estimated. The results from each of

the six possible variations are shown in Appendix A and the average of the time

associated with each interconnectedness classification is shown in Table 3. The

weights are subjective, but are not without justification. For example, there is clearly a

difference between using electronic codes and paper codes. Some electronic codes,

which may be on a website or part of online subscription service, are provided with the

ability to click on the references being made, which brings the users right to the

applicable cross reference. This is less time consuming than flipping through a paper

41

copy of a code to the applicable cross reference. Additionally, the need to retrieve a

paper copy from an office book shelf and then located the referenced section is also

more time consuming than clicking on a referenced code and retrieving it almost

instantaneously. Although the need to physically retrieve a separate code only applies

to MDI or a reference to another code, the ability to retrieve the code, electronically or

the paper copy is predicated on having access to the code. The differences in the

experience level of the code user can also have an impact on the time to move between

the IHS and a cross reference. New engineers will likely spend much more time on

each classification of interconnectedness in comparison to mid and senior level

engineers. Senior level engineers will likely spend less time moving between the IHS

and cross referencing; however, navigational complexity is not necessarily eliminated

with experience and some will still exist regardless of experience. By using Table 3 to

assign values to references made within a code it is possible to identify what forms of

navigational complexity are making specific Chapters and provisions more complex

than others, by amassing these weights in various combinations. This in turn provides

numerical data, which can be used to evaluate the increasing complexity of a code and

potentially reduce it.

Table 3: The five classes of Interconnectedness with the assigned weighting scheme for

each class.

Single Document Interconnectedness

Weights

IHS Intended Hierarchical Structure

0

SDI-1 Provision A refers to another provision within Code A

1.4

SDI-2 Provision A refers to 2.5

42

another Chapter within Code A

Multiple Document Interconnectedness

MDI-1 Provision A refers to a provision of Code B

4.6

MDI-2 Provision A refers to a Chapter of Code B

7.3

MDI-3 Provision A refers to Code B

7

2.4.2. Exception(s)

In addition to the developed metric a manual method of counting the exceptions

within Chapter 10 of the IBC [8] was used to demonstrate the extensiveness of

exceptions and the increases within recent editions. The three examples below show

the differences between how a single exception and multiple exceptions were counted.

This is an important note because in many instances an exception has multiple items

listed, as seen in Example 3. It is important to be accurate, but the intention of counting

exceptions was to demonstrate an increase in complexity and not specifically to

differentiate the several variations of exceptions. The true number of exceptions may

vary slightly due to describing language within the code but the method of adding them

was consistent.

Example 1 – Counted as 4 exceptions

1006.1 Illumination required. The means of egress, including the exit

discharge, shall be illuminated at all times the building space served by

the means of egress is occupied.

43

Exceptions:

1. Occupancies in Group U.

2. Aisle accessways in Group A.

3. Dwelling units and sleeping units in Groups R-1, R-2

and R-3.

4. Sleeping units of Group I occupancies.

Example 2 – Counted as 1 exception

1008.2 Gates. Gates serving the means of egress system shall comply with

the requirements of this section. Gates used as a component in a means of

egress shall conform to the applicable requirements for doors.

Exception: Horizontal sliding or swinging gates exceeding

the 4-foot (1219 mm) maximum leaf width limitation are

permitted in fences and walls surrounding a stadium.

Example 3 – Counted as 1 exception

1013.1 Where required. Guards shall be located along open-sided walking

surfaces, mezzanines, industrial equipment platforms, stairways, ramps

and landings that are located more than 30 inches (762 mm) above the

floor or grade below. Guards shall be adequate in strength and

attachment in accordance with Section 1607.7. Where glass is used to

provide a guard or as a portion of the guard system, the guard shall also

44

comply with Section 2407. Guards shall also be located along glazed sides

of stairways, ramps and landings that are located more than 30 inches

(762 mm) above the floor or grade below where the glazing provided does

not meet the strength and attachment requirements in Section 1607.7.

Exception: Guards are not required for the following locations:

1. On the loading side of loading docks or piers.

2. On the audience side of stages and raised platforms,

including steps leading up to the stage and raised platforms.

3. On raised stage and platform floor areas, such as runways,

ramps and side stages used for entertainment or

presentations.

4. At vertical openings in the performance area of stages

and platforms.

5. At elevated walking surfaces appurtenant to stages

and platforms for access to and utilization of special

lighting or equipment.

6. Along vehicle service pits not accessible to the public.

7. In assembly seating where guards in accordance with

Section 1025.14 are permitted and provided

The basis for counting the number of exceptions was to provide additional

evidence of increasing complexity. However, unlike cross references quantification

and differentiation can be difficult and has been limited to the number of instances.

45

2.5. Results and Discussions

The developed metric is used on the IBC, the National Fire Protection

Association, NFPA 101: Life Safety Code ©, and the Building Code Requirements for

Structural Concrete (ACI 318) to demonstrate its potential. All three of these codes are

widely used throughout the world and provide familiar examples for most building

code users. A complete analysis of an entire code may be necessary to determine all

instances of navigational complexity within a code, but individual chapters and

provisions provide more than adequate evidence of increasing navigational complexity.

Additionally, the results from counting the number of exceptions in Chapter 10 of the

IBC is shown to further prove an increase in navigational complexity within the IBC

between 2003 and 2012.

2.5.1. IBC

The IBC has existed for the past 17 years, starting with the 2000 edition. It has

been updated every three years since. The current edition of the IBC, the 2015 edition,

is likely the most widely adopted building code in the United States. However, like

many other codes, it has been accused of becoming too complex within professional

literature. As a simple test, the 2003 edition was compared to the 2015 edition.

Table 4: Comparing the number of interconnectedness occurrences in three sections of the

IBC in the 2003 and 2015 editions.

IBC Number of Occurrences Code Edition MDI-3 MDI-2 MDI-1 SDI-2 SDI-1 2003 § 403 0 0 0 3 25 2015 § 403 5 0 1 3 76 2003 § 903 16 0 0 0 39 2015 § 903 13 1 1 0 61

46

2003 § 1003 0 0 0 3 27 2015 § 1003 0 0 0 3 31

Table 4 provides the results showing the number of occurrences of each type of

interconnectedness found in three selected sections of the IBC, which includes both the

2003 and 2015 editions. Although this is only a single section it demonstrates that

there is an extensive number of references within the sections. Table 5 shows the

weighted number of occurrences for each section.

Table 5: Comparing the weighted number of interconnectedness occurrences with the

three sections of the IBC identified in Table 4

IBC Weighted Number of Occurrences Total Weight Complexity

Code Edition MDI-3

MDI-2 MDI-1 SDI-2 SDI-1

2003 § 403 0 0 0 7.5 35 42.5 2015 § 403 35 0 4.6 7.5 106.4 153.5 2003 § 903 112 0 0 0 54.6 166.6 2015 § 903 91 7.3 4.6 0 85.4 188.3 2003 § 1003 0 0 0 7.5 37.8 45.3 2015 § 1003 0 0 0 7.5 43.4 50.9

The results show that the complexity has increased within the IBC since the

2003 edition, as literature suggests.

2.5.2. NFPA 101

The Life Safety Code ©[10] has existed for about 100 years and generally has a

code cycle of every three years. The website for NFPA allows free access to the code

and to previous code editions that date back to 1970, which provides the ability to

compare increases in navigational complexity over an extensive period of time.

However, as noted previously, comparing new codes to old codes is not a likely

47

solution to reducing current levels of complexity. Nevertheless, both the 2012 edition

and 2015 editions were used to quantify the increasing levels of complexity.

Table 6: Comparing number of Interconnectedness occurrences in NFPA 101 Chapter 7,

2012 and 2015 editions

NFPA 101 Number of Occurrences in Chapter 7 Code Edition MDI-3 MDI-2 MDI-1 SDI-2 SDI-1 2012 55 0 0 1255 571 2015 55 0 0 1333 604

Table 6 provides the results of the number of occurrences of each type of

interconnectedness found in NFPA 101 Chapter 7 within the 2012 and 2015 editions.

Although this is only a single Chapter it demonstrates the extensive number of

references within the Chapter. Table 7 shows the weighted number of occurrences for

Chapter 7.

Table 7: Comparing the weighted number of Interconnectedness occurrences in NFPA 101

Chapter 9, 2012 and 2015 editions

NFPA 101

Weighted Number of Occurrences in Chapter 7 Total Weight Complexity Code

Edition MDI-3 MDI-2 MDI-1 SDI-2 SDI-1

2012 385 0 0 3137.5 799.4 4321.9 2015 385 0 0 3332.5 845.6 4563.1

The data suggests that the complexity has increased within the newest edition of

NFPA 101’s Chapter 7. Table 8 provides the results of the number of occurrences of

each type of interconnectedness found in NFPA 101 Chapter 9 within the 2012 and

2015 editions.

Table 8: Comparing number of Interconnectedness occurrences in NFPA 101 Chapter 9,

2012 and 2015 editions

NFPA 101 Number of Occurrences in Chapter 9 Code Edition MDI-3 MDI-2 MDI-1 SDI-2 SDI-1

48

2012 67 0 0 199 78 2015 73 0 0 171 87

Table 9 provides the results of the number of occurrences of each type of

interconnectedness found in NFPA 101 Chapter 9 within the 2012 and 2015 editions.

Table 9: Comparing the weighted number of Interconnectedness occurrences in NFPA 101

Chapter 9, 2012 and 2015 editions

NFPA 101

Weighted Number of Occurrences in Chapter 9 Total Weight Complexity Code


2012 469 0 0 497.5 109.2 1075.7 2015 511 0 0 427.5 121.8 1060.3

The data suggest that the complexity has decreased between the 2012 edition

Chapter 9 and the 2015 edition Chapter 9, which is contrary to what many engineers

speculate about codes, and to the results of Chapter 7. However, this chapter was used

as example, because the primary reason for the difference is the lack of a reference to

Chapters 11 through 43 in the 2015 edition. The 2012 edition references Chapter 11

through 43 seven times and the 2015 edition does so only 6 times. References to

blanket chapters can be misleading, because not all chapters are actually applicable. If

in fact only one chapter was applicable out of chapters 11-43, which is likely, then the

2015 edition would indicate an increase in complexity.

2.5.3. ACI 318

The ACI 318 is similar to most NFPA codes and standards in that it is typically

referenced by a building code like the IBC. Additionally, the ACI 318 has existed for

an extensive period of time and has history. The President of the American Concrete

49

Institute wrote an article in 1974 titled, “The 1971 ACI Building Code Too

complicated, too complex or both?”, which as the title infers, is questioning whether or

not the 1971 edition is too complicated or too complex [12]. This is important because

it shows that the code was likely considered complicated or even too complex 45 years

ago. Without any revisions or major changes to the code, the complexity added over

the years has likely furthered the issues. However, the 2014 edition was promoted as

being a completely reorganized document.

In preparation for the 2014 edition, several previous editions were examined

and subjected to the developed metric to determine if navigational complexity had

increased over the years. Table 10 provides the results.

Table 10: Comparing the weighted number of Interconnectedness occurrences in the ACI-

318 Chapter 5, 1971, 1995, 2005 and 2011 editions

ACI-318 Weighted Number of Occurrences in Chapter 5 Total Weight Complexity

Code Edition

MDI-3 MDI-2 MDI-1 SDI-2 SDI-1

1971 14 0 0 2.5 2.8 19.3 1995 77 0 0 17.5 60.2 154.7 2005 77 0 0 17.5 56 150.5 2011 112 0 0 20 65.8 197.8

Although there appears to be a slight decrease in complexity between 1995 and

2005, in general complexity has significantly increased since 1971. The increase in

navigational complexity is on the order of 10 times more complex, but it does not seem

possible that if the 1971 edition was too complex that a subsequent editions 10 times

more complex is usable. Granted, a single chapter does not have to represent an entire

code, but it is clear that the code has grown in size and this chapter likely provides a

good representation of all chapters.

50

Table 10 shows that navigational complexity has drastically increased over the

editions; however, what is not evident is that Chapter 5 of the 1971 edition contains 22

sections and subsections and the entire chapter fits on a single page. The same chapter

of the 2011 edition contained 116 sections and subsections and covers about 9 pages.

This means that not only has the number of references increased, but the document has

also grown in size. The number of sections is noted because although there is a semi-

direct relationship between the number of provisions and the size (number of pages),

the increased number of provisions signifies an increase hierarchical structure.

The 1971 edition has about 80 pages total and the 2011 edition has about 500

pages. Although the 500 pages of the 2011 edition also include commentary, which

may be about half of the document, 250 pages would still be three times the size of the

1971 edition. The 2014 edition has 520 pages (with commentary) a slight increase

from the 2011 edition, but expected based on the increase in page count of almost every

code examined.

If the 1971 edition was/is considered too complex and if the recent editions are

more complex, then they too are likely too complex. The assertion that the 1971

edition was too complex is probably correct in a certain context, because it may have

been unnecessarily complex, just as any of the new editions might. However, it is not

likely that it was too complicated or too complex based solely on the fact that the newer

editions have shown a significantly increased amount of navigational complexity. Each

of the editions have been used for several years, meaning that they were likely not too

complex for use. Comparing a newly re-organized code to an older code would

generally require a complete measure of complexity, but considering the 2011 edition

51

had over 2500 provisions, this would not be practical. Even just a chapter to chapter

comparison is likely to have instances of changes to the code structure, which could be

like comparing different chapters. The differences between the 2011 edition and 2014

edition are outlined [18] and a transition key is provided by the ACI-318 committee

[18].

Instead of examining both the 2011 and 2014 editions for similar provisions that

may or may not have added references suggesting an increase in complexity, it was

decided to search each document for indicators of references. Indicators being phrases

that would be the lead into a reference. The search used both code and commentary

and the results represent both. Although the results are not an exact reflection of each

code alone, they are still representative of a general level of complexity. The results

are shown in Table 11.

Table 11: Indicators of references and quantities in the 2011 and 2014 editions of the ACI-

318

AC

I-31

8 E

diti

on

“req

uire

men

ts o

f”

“in

acco

rdan

ce w

ith”

“req

uire

d by

”

“in

Cha

pter

”

“Spe

cifi

ed in

”

Tot

al

2011 173 213 131 40 49 611 2014 159 763 111 79 41 1153

Table 11 shows that most indicators within both editions are similar with the

exception of “in accordance with”, which the 2014 edition has over three times as many

as the 2011 edition. This does not necessarily mean that there are three times as many

52

references in the 2014 edition, but it does suggest that there are likely more. There are

two caveats that must be understood. The first is the number of chapters searched:

2011 edition – Chapters 3-21 and 2014 edition – Chapters 3-27. Meaning there is

likely more references to other chapters in the 2014 edition because it has more

chapters to references. The second caveat is that some use of “in accordance with” is to

sub-provisions and immediately adjacent provisions, which does not necessarily mean

added complexity. However, the significant increase in the use of “in accordance with”

indicates a shift in the structuring of the code and some added complexity.

2.5.4. Exceptions within the IBC

Exceptions are unintended structural features of a code because they can often

lead the user away from the natural path in the same ways references do. In fact, many

exceptions include references, which may be a variation of the developed metric.

However, the importance of exceptions should be noted. Exceptions allow such items

as spiral stairs to be used, which would otherwise not be permitted as the result of

blanket statements. The following provision from the IBC [8] is an example of this.

1009.7.3 Winder Treads

Winder treads are not permitted in means of egress stairways except

within a dwelling unit.

Exceptions:

1. Curved stairways in accordance with Section 1009.11.

2. Spiral stairways in accordance with Section 1009.12.

Rather than listing all instances where something is to be included it is easier to

require it everywhere and take out the few places it is not required. This practice is

53

utilized in almost all codes. However, the significant amount of exceptions is not

negligible, as seen in Table 12.

Table 12: The number of Exceptions within four editions of the IBC

Code Edition Number of Provisions

Number of Exceptions

Number of Exceptions per

Provision

2003 293 248 0.85

2006 295 288 0.98

2009 353 318 0.90

2012 384 330 0.86

The results shown in Table 12 illustrate an increase in both the number of

provisions and the number of exceptions in four editions of the IBC. After reading

Chapter 10 it is evident that the number of exceptions can be overwhelming. Although

there are many provisions with multiple exceptions, which are not clear in the results,

there is still almost as many exceptions as provisions, i.e. the number of exceptions per

provision ranges from 0.85 to 0.98.

2.6. Conclusion

Navigational complexity is an issue of interest for various reasons, but

complexity is exactly that, complex, and despite the fact that the metric does not

completely solve all the issues it does provide some important information. The metric

for quantifying navigational complexity outlined may have multiple uses in addressing

some of the issues. It is relatively easy to implement measures of single and multiple

document interconnectedness. Both can provide more details on navigational

complexity. The developed metric has shown that complexity and specifically

54

navigational complexity has increased in three commonly used codes. This provides

proof to the idea that many practicing engineers have long believed. The metric can be

applied to other codes both locally and globally as shown. The results do not directly

confirm that building codes have become too complex, but may provide the

justification for consideration of taking steps to reduce the navigational complexity of

codes.

References



3. MacGregor, J. G. "A Simple Code-Dream or Possibility?." Special Publication72 (1981): 199-218.


5. Searer, G., et all. 2007. “Are we really learning from Earthquakes? Declining Quality and Increasing Complexity of Modern Building Codes”. In Proceedings of the 9th Canadian Conference on Earthquake Engineering. Ottawa, Canada, June, 2007.

6. Mathews, D. D. "Towards a European Code for Concrete–Can Concise Codes be Comprehensible and Comprehensive?." The Structural Engineer 54.12 (1976): 476-477.


8. International Code Council, et al. International building code. International Code Council, 2015.


55

10. National Fire Protection Association. NFPA 101 Life Safety Code. National Fire Protection Association, 2015.



13. Building Code Requirements for Structural Concrete: (aci 318-71). Farmington Hills, Mich: American Concrete Institute, 1971.

14. Building Code Requirements for Structural Concrete: (aci 318-95) ; and Commentary (aci 318r-95). Farmington Hills, Mich: American Concrete Institute, 1999.



17. ACI Committee 318. "Building Code Requirements for Structural Concrete (ACI 318-14): An ACI Standard: Commentary on Building Code Requirements for Structural Concrete (ACI 318R-14), an ACI Report." American Concrete Institute, 2015.

18. Ghosh, Satyendra K. "Significant changes from the 2011 to the 2014 edition of ACI 318." PCI Journal 61.2 (2016

19. ACI Committee 318. "Building Code Requirements for Structural Concrete (ACI 318-14): ACI 318-11 to ACI 318-14 and ACI 318.2-14, Transition Key." American Concrete Institute, 2015.

56

CHAPTER 3: REDUCING COMPLEXITY THROUGH GRAPHS

Abstract

Building codes are complex for several reasons and attempting to make codes

less complex is not trivial. The complexity of building codes has been shown to be

increasing in several commonly used codes and it may be necessary to simplify some

codes. However, without a method to reduce complexity, the task of simplification

may be impenetrable. A metric for quantifying navigational complexity has previously

been developed and the developed metric was used to show navigational complexity

numerically, but the metric can also show navigational complexity graphically.


referencing and other unintended structural features of a code. The combination of

numerical data and graphical representations may provide a significant advantage that

is not yet realized. This research focuses on a method of measuring and graphically

representing navigational complexity, to identify areas where navigational complexity

can be reduced. Measuring and understanding navigational complexity within any code

opens up the possibility of mitigation through reorganization and developing better

navigational tools for future editions.

3.1. Introduction

How navigational complexity can be quantified and how it has increased in

recent editions of several commonly used codes was shown in Chapter 2. Navigational

complexity, specifically cross referencing, can be an important part of individual codes

57

and code networks. The following excerpt outlines the importance of cross

referencing:

Now assume that a particular building code entitled the Y building code

were to reference the Accessible Design Standard X under the Y Code's

chapter regulating design for people with disabilities. This Y code would

be much greater in scope than the X Standard, as accessibility would be

only one of the concerns of the Y code. The Y Code would also regulate

the many fire safety, health safety, and structural safety concerns that are

not related to accessibility. Many other standards would be referenced by

the Y code and even other codes could be referenced by the Y Code. The Y

Building Code, in its adoptions by many different communities would help

promote more consistent and higher quality design throughout a large

geographical area [1].

Similarly, “Anyone who has taken the trouble to examine building codes knows

that many of them refer to certain standards, often with very sketchy identification and

as amended from time to time. The purpose, of course, is to take advantage of the

existence of reliable engineering material in its most up-to-date form [3].” The

importance of cross referencing does not appear to be questioned in literature. The idea

that cross referencing strengthens, not only individual codes, but the entire code

network is certainly reasonable. This is because building code complexity is not

limited to individual codes, but is likely also a function of the entire network of codes.

However, building codes have been added to over the years and, “… it is wrong

to continue indefinitely to add, add, add to the tools of knowledge, without combination

58

or elimination [2].” This statement is of significant importance to this research,

because codes have significantly grown in size with little combination and less

elimination. Although the author may not have been specifically talking about

complexity, it is certainly not out of the realm of their intent. Continually adding to

codes is a recipe for creating standardization and/or complexity where it is not

necessary. The idea that codes have been added to unnecessarily is also evident in

literature, “other things are creeping into the building code that go well beyond the

purpose of the building code [4].” This suggests that there is likely some middle-

ground, where some cross referencing is necessary, but other instances where it is just

creating complexity unnecessarily. This idea is supported by, “I believe that the

complications and complexities of the Code are, in many cases, justified and, in some

cases, inevitable; but many of them are remediable [5].” Thus, identifying and

removing unnecessary cross references appears to be a viable solution to solving

increasing navigational complexity within building codes.

Chapter 2 of this research demonstrated the use of a metric for quantifying

navigational complexity numerically. It also confirmed that the navigational

complexity has increased in recent editions of several commonly used codes. Chapter 3

of this research expands the use of the developed metric to include graphical

representations. Through the use of graphical representations, it is possible to identify

codes and provisions of importance with respect to navigational complexity. By

identifying important codes and provisions it may be feasible to reduce unnecessary

cross references while maintaining the necessary cross references. The basis for

Chapter 3 of this research is twofold: 1) demonstrate importance graphically, by

59

“globally” and, “locally” representing codes and code networks and 2) demonstrate that

reducing navigational complexity within a building code is feasible.

3.2. Background

The interconnectedness of codes were classified in one of two categories in

Chapter 2: Multiple Document Interconnectedness (MDI) and Single Document

Interconnectedness (SDI). MDI is considered a macro-type scale (global), as it can

encompass a wide range of codes; while SDI is considered a micro scale (local),

because it only focuses on a single code. Table 13 was developed in Chapter 2 and

provided the basis for confirming that navigational complexity existed. Based on

literature it can be assumed that some cross referencing is necessary. This assumption

suggests that the codes and provisions that are making the necessary cross references

have more importance than those that are making unnecessary cross references. The

caveat being, the importance specifically refers to the necessity of a reference and not

the importance of a code or provisions contents.


each class.


Weights


0


1.4

SDI-2 Provision A refers to another Chapter within Code A

2.5

60



4.6


7.3


7

The hierarchical structure of almost all codes consists of the numbered chapters,

sections and provisions within the document, and these can be considered the intended

hierarchical structure (IHS). This IHS forms the natural path that a code user steps

through until they have all the information necessary to their project. The IHS in

Figure 2 is relatively simple and represents what the IHS of what some codes looks

like.

Figure 2: Intended hierarchical structure of Chapter 5, 1971 Edition ACI-318 [8].

The natural path of each sequential provision is straight forward; however,

navigational complexity can disturb the natural path. Navigational complexity is

61

defined as the complexity created by document cross referencing and other unintended

structural features of a code. Additionally, caution must be taken because some codes

contain multiple layers of sections and sub-sections. Provisions with multiple layers of

sub-provisions are known as Extensive Hierarchies. Navigational complexity can be

exacerbated by extensive hierarchies.

3.2.1. Code/Provision Importance

For practical purposes, it is important to relate the effects of cross referencing to

a universal concept. An analogy is the universal concept of transportation. Below is a

sample comparison of the different classes of cross references and how they can be

related to moving around a city:

SDI-1: Provision A references Provision B – This would be similar to

running an errand along one’s current route home. It is relatively easy.

SDI-2: Provision A references Chapter B – This would be like running an

errand in the opposite direction of the route home. Not overly

complicated, but can be, depending on the situation.

MDI-1: Provision A references Code B Section X – This would be like a

going to a specific place in a different city before going home.

Complicated and time consuming.

MDI-2: Provision A references Code B Chapter Y – This would be like a

going to general location in a different city before going home. More

complicated and time consuming.

62

MDI-3: Provision A references Code B – This would be like a going to a

different city before going home from work. Very complicated and time

consuming.

The general assumption is that the code user would be reading a code in

chronological order, and any cross reference would be a “detour” or deviation from the

natural path. The user would be required to return to the original path or provision so

as to move to the next sequential provision. Although the examples are very general,

they do show that the different references provide various levels of complexity, which

necessitates the weighting scheme.

In transportation, there are often hubs or locations where travel both comes to

and goes from. These locations are of significance because any alteration or

modification to them can drastically affect other areas. This may not seem important or

relevant to navigational complexity of a code at first; however, by using the

transportation analogy the importance of a cross reference to/from a code or a provision

can be put into better perspective. If a code is referenced by other codes, a change

within that code could affect the referencing codes, which may be analogous to creating

a beltway. The beltway essentially limits traffic to the city. Although there are times

when it is necessary, careful attention must be made to not divert the necessary traffic.

Similarly, if a code stops making a reference then that code could be lacking necessary

information, which would be like blocking a road out of a city. The same concepts can

be used for provisions, which also make references and are referenced by other

provisions.

63

Code importance and provisional importance is based on navigational

complexity and are based on the same principles that make a transportation hub

important. The amount of information flowing through a code or provision generally

signifies importance. This might be an oversimplification, but this is no different than

basing the importance of transportation hubs on flow. Items like the speed limit

through a hub or how long it takes to get through a hub may impact individuals, but do

not necessarily impact over all flow. Therefore, basing the importance of a code or

provision on navigational complexity alone is justifiable.

The differences between code and provisional importance are similar to the

differences between vehicle and air transportation. SDI is related to provisional

importance and would be similar to vehicle transportation and MDI is related to code

importance and is similar to air transportation. There are times when they can and

cannot be lumped together, and therefore, the significance of SDI and MDI, as

discussed previously in Chapter 2, must be fully understood. Any alterations or

modifications to SDI or MDI can have drastic results, which is no different than an

airline stopping service to an airport or a traffic pattern change within a city.

There are certain codes that are fundamentally more important than others. This

seems intuitive, but in actuality the importance of a code may not fully depend on how

well-known it is or how much it is used in the field. Instead, the importance of a code

may have more to do with the amount of information that it controls, i.e. the amount of

information flowing in and out of the code. This idea is an extension of the influence

and centrality concepts of graph theory [6], which is also similar to PageRank, and the

ranking system Google uses for websites. In Chapter 2 navigational complexity was

64

mostly discussed as the interconnectedness within a code, because determining the

quantity of code to code references requires examining entire codes. Examining the

reference section of individual codes provides minimal information on complexity

within that code, but in terms of a code network the same principles can be applied to

codes as a whole, that would normally be applied to a single code. By inputting all the

references from various code reference sections, it is possible to identify which codes

can be considered important.

Determining provisional importance can be done in a similar fashion as code

importance. All references within a code can be inputted and provisions of importance

can be identified by the quantity of references being made to it. However, mapping the

HIS of an entire code and all the references made within the code is labor intensive. It

requires inputting every piece of the IHS and then identifying all references made. If it

were possible to have the language of complete codes in a form that could be utilized

on a computer this may be simplified, but for the time being, the process is limited to

manual methods. Additionally, unlike code importance, which can make numerous

references, most provisions make a few references at most. Therefore, provisional

importance is likely difficult to determine even within a Chapter.

3.2.2. Graphical

Navigational complexity interferes with the natural path of a code through cross

references and other unintended structural features, such as figures and tables. This

research is primarily focused on the navigational complexity created by cross

references. A cross reference can deviate a code user a short distance, i.e. to another

65

provision, or a long distance, i.e. to another code. Although these deviations can be

captured numerically, as shown in Chapter 2 of this research, the numerical data alone

is difficult to use. This led to the idea of representing the codes and navigational

complexity graphically.

The idea of representing the cross references graphically allows for counting

references, both in quantity and complexity level, and shows how the references are

interconnected. Simply counting the number of references does provide numerical data

and a general sense of which codes, chapters and provisions may be more complex;

however, in order to better represent complexity, that abstraction of a graphical

representation is necessary. The metric was expanded to include graphical

representations, providing a more robust approach to reducing complexity within a

single code and between multiple codes.

Representing navigational complexity graphically led to the idea of

incorporating some aspects of graph theory. Although there are other aspects of graph

theory, only the basics are needed to represent navigational complexity graphically, and

they are described below:

A. A node (a circle or dot, representing in this case, a provision within a

Chapter of the IBC, an entire Chapter, or a separate Code)

B. An edge (a line representing a link between two codes, which is a cross

reference within a specific provision)

Without going into detail, one of the easiest ways to explain how graph theory

was used is by making a family tree. Parents and children are nodes and are connected

to one another by edges. It is typically simple at first, but there are different types of

66

connections in a family tree. For example, the connection between a husband and wife

is not the same as between mother and child. Therefore, in order to make graphical

representations a useful tool in representing navigational complexity, they must be

combined with a quantifiable method for measurement, which is based on the different

types (classes) of interconnectedness developed in Chapter 2.

Figure 3 is the IHS combined with the references that are made within the

specific provisions of the chapter. Extensive hierarchies can make visualization

difficult; however, it is necessary to include the IHS within the graphs for

completeness. Although the graph is not overly complex, it does show that the

references made within the provisions has significantly altered the natural path(s). The

graph could be rearranged in almost any infinite number of orientations, but the intent

is to show the graph in the least complex configuration. This means having the least

amount of crisscrossing edges (references) visible on the graph. The graph makes it

difficult to distinguish between what the IHS is and what was added from references

made within the provisions and requires further detail to provide the necessary

differentiation.

67

Figure 3: A graphical representation of intended structure along with SDI and MDI added to

Chapter 5, 1971 Edition ACI-318 [8]

Navigational complexity can be visualized with the graphs, but the graphs alone

do not provide differentiation between IHS and references. The supporting numerical

data provided by the metric/weighting scheme can be used to better differentiate

between the IHS and the references. Including the weighting scheme can be done in

various ways, line weights and color being the two simplest. Figure 4 incorporates the

weights from the weighting scheme with the combined IHS and references. Again, this

is only a simple example, but the graph shows where and how navigational complexity

is being added to a chapter of a code.

68

Figure 4: A graphical representation, including the weights from weighting scheme added to

Figure 3

In Figure 4 the IHS is represented by the thin black lines and the cross

references are represented by the red lines. The thicker the red line the higher the

weight of complexity, i.e. a MDI-3 reference. The simple combination of graphs and

the weighting scheme provides the necessary differentiation between IHS and cross

references. By having differentiation, it may be possible to mitigate navigational

complexity, identifying unnecessary cross references.

3.3. Methodology

A complete examination of entire codes would be necessary to determine all

instances of cross referencing within any given code, but the techniques, weighting

scheme and graphical representations, can be applied locally or globally. However, as

noted, it is difficult to demonstrate provisional importance globally or even within a

single chapter. As such, code importance is demonstrated globally and provisional

importance is demonstrated locally, in the selected provisions.

69

3.3.1. Globally

For statistical sampling purposes, ten NFPA documents (Codes and Standards)

were chosen and examined by collecting the references cited in each of the reference

publication chapters. These documents were chosen based solely on the authors’

familiarity with them and for the simplicity of a small subset. Data were collected by

noting whether or not any of the references were a match to one of the ten chosen

codes. By using a small subset of the NFPA documents as a statistical sample to limit

the number of references to one of the ten codes, the matrix created was 10x10. A

comprehensive analysis would have resulted in a matrix with a size on the order of

375x375, based on the number of NFPA documents alone. From the matrix, it is

possible to determine how many times each code was referenced by one of the other

nine codes as well as how many references each code made.

The reference publication chapters of all NFPA documents were examined in

2012, as part of another project. A large matrix was created and constrained to only

NFPA documents, which at the time was approximately 300 documents. The results,

which were not initially used to investigate code importance, have been used to

compare the levels of importance of all NFPA documents at the time.

3.3.2. Locally

For the simplicity of demonstrating the metric only, Chapter 9-Fire Protection

Systems of the IBC is used. To demonstrate that the combination of numerical data and

graphical representations can be used to reduce the navigational complexity within

Chapter 9, a systematic breakdown of Chapter 9 was necessary.

70

Each provision of the chapter was documented in chronological order. The

number of provisions is an approximation because some high-level provisions do not

provide any information but are used instead as headers. The number of provisions was

counted by including each numbered provision, regardless of content. Each provision

was examined for references and each reference was documented. However, there are

some other caveats to how the data were collected. Two are of primary significance for

this research. The first being any references within a provision to sub-provision

directly below were omitted and any references to a parent provision were also omitted.

These types of references would be similar to the connection between a mother and

child or a child and mother. The connection already exists and although the additional

reference may contribute to more complexity, quantifying it within the metric is not

essential.

3.4 Results and Discussion

3.4.1. Globally

Knowing the amount of navigational complexity between codes may be of some

value, but likely contributes little to the understanding of navigational complexity

within a specific code. However, to determine code importance by using MDI or the

reference section of a code is relatively simple and may provide insight into code

complexity of the network. Using MDI references to measure code importance can be

done with numbers alone, but using simple charts can make comparison easier to

visualize. The results shown in Table 14 are from the examination of the reference

71

publications section of ten NFPA codes and standards. The matrix was constrained to

the ten documents and is not a complete representation of all references.

Table 14: Ten selected NFPA Codes (and Standards) and associated references limited to

the ten selected.

NFPA 1 NFPA 13 NFPA 25 NFPA 30 NFPA 54 NFPA 70 NFPA 72 NFPA 90A NFPA 101 NFPA 5000

NFPA 1 X X X X X X X X X

NFPA 13 X X X X X

NFPA 25 X X X

NFPA 30 X X X X X

NFPA 54 X X

NFPA 70

NFPA 72 X X X X X

NFPA 90A X X X X X

NFPA 101 X X X X X X X

NFPA 5000 X X X X X X X X

Figure 5 and Figure 6, show the number of references (outgoing) made by each

code and the number of references (incoming) to each code respectively. Neither chart

appears to provide any valuable information with regards to which codes may be more

important than others. The small sub-set is likely the major contributing factor to this,

because within the network of NFPA documents, ten is a relatively small sample. It is

interesting to note two particular codes, NFPA 1 and NFPA 70. NFPA 70 does not

make any references, but is referenced by all but one of the nine other codes, while

NFPA 1 references all nine other codes, but is only referenced once. It does take prior

knowledge to know the scope of these documents, but, even without prior knowledge

of each code’s scope, these anomalies are noticeable. However, with prior knowledge

of NFPA 1 and NFPA 70 it would be known that these are two of the most commonly

used codes in the United States, and that the number of incoming and outgoing

references alone does not appear to be an accurate measure of importance. Otherwise,

72

on one chart NFPA 70 is important, while NFPA 1 is not and vice versa on the second

chart.

Figure 5: The number of References made within each of the selected NFPA Documents.

Figure 6: The Number of Times each Selected NFPA Document is Referenced

In order to measure code importance, it appears that both the Incoming and

Outgoing reference numbers should be used in combination. By creating a

combination of Incoming and Outgoing references, a better representation of each

73

code’s importance is provided. This is based on the assumption that both NFPA 1 and

NFPA 70 are in fact important. The results shown in Figure 7 are still slightly

ambiguous, but expected, because the simplified data set is constrained. The further a

code is away from the origin the more likely it is to be important. Codes furthest from

the origin would be those that are both being referenced and making references. This

information can be helpful, but does not necessarily confirm whether a specific code is

navigationally complex.

Figure 7: Code Importance - Combination of Incoming and Outgoing References

The value of determining the importance of a specific code will likely manifest

when investigating navigational complexity with regards to SDI and MDI within single

codes. This is because if a code is deemed or considered complex, but is not deemed

important with regards to other codes then the code may have issues with navigational

complexity. Similarly, codes that are heavily referenced or make lots of references but

74

not both can be navigationally complex and any modifications or alterations to that

code may have broad effects that are not easily understood.

The results shown in Figure 8 are from the entire matrix of NFPA codes prior to

2012, roughly 300 documents constrained to references to one another. Again, without

prior knowledge of a specific code’s scope, the chart provides a limited value in terms

of the investigation into navigational complexity, but it does indicate importance of

individual codes. However, some generalizations can be made. For example,

approximately 87 percent of the NFPA documents make less than 20 references and are

referenced 20 times or less. This number of references being made seems relatively

manageable in terms of navigational complexity. Although incoming references do not

generally affect navigational complexity within the referenced code, the effects of

modification or alterations within a specific code seems to also be manageable with

only 20 incoming references. However, there is a notable number of outliers that

appear to have significant importance.

75

Figure 8: Code Importance for all NFA documents (pre-2012) - Incoming References vs Outgoing

References

Figure 9: Top Ten Important NFPA documents

A closer look at the top ten NFPA documents, Figure 9, reveals that many of the

most commonly used documents are present. This is likely not a surprise to code users

who are familiar with the references within these documents. Any changes made

76

within outlier codes can have rippling effects on the other codes, and users have likely

noticed a change in one document affecting another previously. The extent to which

changes are affected is likely not well understood. Additionally, the importance of

some codes, such as NFPA 10: Standard for Portable Fire Extinguishers, which is

generally an ancillary document, is surprising. The significance of a document, such as

NFPA 10, should be understood or at least acknowledged, because it may not be a

navigationally complex document but it can certainly affect information flow.

3.4.2. Locally

The importance of a single provision may not be readily apparent when looking

at the IHS or even a graph including cross references. When investigating cross

references, the directionality of a reference is limited to outgoing references, i.e. a

reference from one provision to another. However, to fully understand provisional

importance it may be necessary to consider references being made to a given provision.

This task is not easily dealt with, because it requires knowledge of an entire code.

Unlike code importance, which can generally be captured by the reference section of a

code, provisional importance can exist solely within the provisions of a document and

requires some form of manual identification. It may be possible to use the IHS and

create an algorithm to extract references from within a document, which could then be

used to identify important provisions, but even that would be labor intensive. However,

the major hurdle would be getting a code in a format that could be inputted into a

computer. Most codes are not available in a format that is viable for this type of input.

There are several reasons for this and are outside the scope of this research.

77

As noted, Chapter 9 was examined by identifying each individual provision and

then documenting any cross references within those provisions. The results based on

the classes of interconnectedness are shown in Table 15.

Table 15: Cross reference type and number of occurrences-


Number of Occurrences


167


69



1


0


128

The results shown in Table 15 demonstrate that there is a significant number of

cross referencing occurring. The number of provisions within Chapter 9 is

approximately 495. This is an approximation because some high-level provisions do

not provide any information but are used instead as headers. What is not evident in the

numerical results is the actual number of additional pieces that are added. For example,

although there are 128 instances of a provision referencing another code it does not

mean that each reference was to a different code. Initially, all of the data from Chapter

9 were sorted, but it was determined that looking at individual sections would provide a

better starting point. By examining Section 903 separately, Table 16 was developed.

78

Table 16: Reference type and number of occurrences within Section 903


Number of Occurrences

SDI-1

Provision A refers to another provision within Code A

25

SDI-2

Provision A refers to another Chapter within Code A

10


MDI-1

Provision A refers to a provision of Code B

MDI-2

Provision A refers to a Chapter of Code B

1

MDI-3

Provision A refers to Code B

13

The numbers are only a subset and do not provide any more particularly

important information. Differentiating each type of reference is important because they

are necessary to the graphical representation. However, there are a few caveats that

must be addressed prior to inputting the data into a graph. The number of occurrences

of any single type of cross reference does not mean that it is actually the number of

separate provisions referenced. This is of particular significance because, for example,

of the 13 references to another code within Section 903, there are only 7 different codes

referenced. This is where the use of graphical representations became important to

fully develop the metric. Representing the hierarchical structure of a code creates

thousands of nodes and edges before the cross references are even included. Although

it is not difficult to create a graph of the entire hierarchical and cross referencing

structure of a code, it is difficult to fit it on a single, readable, page. Thus, for

simplicity sub-section 903.3 is used and is shown in Figure 10.

79

Figure 10: A graphical representation of the hierarchical structure of sub-section 903.3

In theory, the hierarchical structure of a building code should resemble a tree.

As a simple analogy, the provisions represent the leaves, Sections the minor branches,

Chapters the main branches and the Code itself the trunk. Although, as shown in

Figure 10, sub-section 903.3 would need some manipulation to look like an actual tree,

it does have some resemblance. Looking at the hierarchical structure alone does not

provide much insight, because without knowing what information is within the

provisions themselves the level of complexity cannot be ascertained. It is therefore

necessary to include the cross references within each provision; Figure 11 shows the

cross references connected to their specific provisions.

80

Figure 11: A graphical representation of sub-Section 903.3 with hierarchical structure and cross

referenced provisions

A simple visual inspection indicates that the complexity of Figure 12 is greater

than Figure 11; however, as noted before, when there are multiple instances of

references to the same code, careful attention must be given so that identical nodes are

not created. For example, NFPA 13 is referenced four separate times by four separate

provisions, and this added complexity must be captured. In Figure 11 the references to

NFPA 13 are seen, but showing NFPA 13 four separate times is incorrect. NFPA 13

can only be shown as a single node, because the “information” each cross reference is

81

looking for comes from the same NFPA 13. By further inspection it is clear that sub-

section 903.3.1 is also shown multiple times. Reorganizing Figure 11 to eliminate

multiple occurrences of provisions or codes leads to the graph in Figure 12.

Figure 12: A graphical representation of sub-section 903.3 with cross references combined to

eliminate multiple occurrences

The interconnectedness of the sub-section becomes more noticeable in Figure

12. The edges (connections) stayed the same, but the number of provisions is reduced.

However, to make identifying potential areas of concern within the graphs easier to

recognize, it is best to incorporate the weighting values described previously in Table

82

13. This can be done by color, simple line weight differentiation, or a combination of

both, and allows for the production of a more robust metric. Figure 13 shows the

difference between the connections created by the intended hierarchical structure and

the cross references, along with the differences between different types of cross

references.

Figure 13: A graphical representation of sub-section 903.3 with all provisions, cross references and

weighting scheme

83

With the metric generally outlined/developed, the final step is determining the

feasibility of reducing navigational complexity. Since reducing navigational

complexity is the goal, then it is necessary to demonstrate how it can be reduced, at

least to some extent. By looking at the different cross references in Figure 13 it may

not be obvious which references might be candidates for modification or elimination.

Based on the weighting scheme, there are only two types of interconnectedness present,

SDI-1 and MDI-3. In principle, the only way to reduce an interconnection of SDI-1

would be to eliminate it, so what can or cannot be removed is likely something a code

committee would debate. However, the complexity of an interconnection of a MDI-3

type can be reduced by making it more specific, i.e. MDI-1 or MDI-2. Sub-section

903.3.2 references a definition within NFPA 13, but upon inspection the definition is

located in a specific location within NFPA 13. Thus, in theory, the interconnection

between 903.3.2 and NFPA 13 could be modified to an interconnection type MDI-1.

The exact location of the referenced provision may change without the IBC code

committee’s knowledge and therefore, it may be decided leave it as a MDI-3

interconnection; however, the feasibility of the metric appears to confirmed.

3.5. Conclusion

The ability to visualize the navigational complexity created by cross references

is only beginning to be understood. Graphical representations of codes provide a

significant advantage over numerical results alone, because the graphical

representations can help make identifying unimportant cross references possible.

Additionally, with the combination of the developed metric in Chapter 2 and the basics

84

of graph theory outlined within this research, it can be used to identify important codes

and provisions, specifically those that control the flow of information in and out of their

respective codes. Using the graphs to understand the differences between the intended

hierarchical structure of a code and the actual structure may provide a means to making

codes easier to use and less complex.

References


2. Cross, Hardy. Engineers and ivory towers. McGraw-Hill, 1952.


4. Pierson, D., “Who Hijacked My Building Code?”, Structure Magazine, (April, 2016): 66.


6. Sporns, Olaf. Networks of the Brain. MIT press, 2010.


8. Building Code Requirements for Structural Concrete: (aci 318-71). Farmington Hills, Mich: American Concrete Institute, 1971.

85

CHAPTER 4: A CASE STUDY OF ELEMENTARY SCHOOLS AND THE

ASSOCIATED FIRE ALARM SYSTEMS

Abstract

Demonstrating the existence of navigational complexity within building codes

is rather straight-forward. Additionally, demonstrating an increase in navigational

complexity within building codes over the years is also relatively straight-forward.

However, navigational complexity can be subjective and vary depending on the specific

code being used. This case study places navigational complexity within the confines an

actual design scenario and reveals the increase in navigational complexity over the

years. This study presents why navigational complexity poses a real issue within a

single code and how compounding navigational complexity between multiple codes is

also an issue of concern.

4.1. Introduction

The idea for this case study is based on a project involving an addition to a

small special needs school. The fire alarm system within the current school was

outdated and because the new addition would also require a fire alarm system, the

owner wanted to remove the old system and provide a completely new system

throughout the combined building. Since the State of Maine was currently still using

the 2009 International Building Code (IBC) the school did not have to provide an

Emergency voice/alarm communication system, only a fire alarm system. However,

because of the State’s involvement with all school projects and their knowledge that

86

subsequent editions of the IBC would require an Emergency voice/alarm

communication system, they felt the school should provide the more robust system.

The school was not obligated to meet the requirements of a not yet adopted code and

resisted, primarily because of the associated cost increases. The fundamental code

issues involved with that project form the basis of this case study.

This case study looks at the development of the requirements for elementary

schools (educational occupancies) within the building code over the past 60 years and

specifically the requirements for fire alarm systems within an elementary school. An

actual design scenario is provided, which is assumed to occur regularly in the field.

There are a limited number of elementary schools built every year and they are

distributed throughout the country. The design of a school is not restricted to those

architects or engineers within close proximity, but in general, experience suggests that

in actuality it is somewhat limited. Therefore, it is likely that many design firms are

working on school projects and the number of projects any one firm is working on is

limited. The intent is to demonstrate that there is an issue with increasing navigational

complexity within the building code and it can be coupled with the navigational

complexity increasing within a referenced code.

Navigational complexity is subjective and for every example demonstrating

why navigational complexity is an issue there may be a valid counter; however, this

study considers those architects and engineers involved with building codes, who are

constantly working on different types projects. The premise that there are engineers

constantly working on different projects is based on the authors experience and the

simple fact there are approximately 26 different occupancy types and nine construction

87

types within the International Building Code. Clearly there are a significant number of

variables when considering occupancy and construction type alone. Although this does

not necessarily suggest that there are significant variations within the provisions of the

remaining code; it does however suggest, that there is a need to differentiate between

occupancy and construction type. This in turn suggests that there are some differences

in the remaining provisions.

4.2. Background

There are some engineers who use a code to solve a specific design problem

repeatedly. This leads to familiarity with the code and likely renders navigational

complexity irrelevant within the scope of a narrow subset of that respective code.

However, there is a drastic difference between those using a code for repeated design

and those who do not. This can easily be shown in the comparison of a contractor’s

sprinkler designer, who designs residential sprinklers systems every day, versus an

individual in an A/E firm who designs sprinkler systems when needed. The sprinkler

designer working for a contractor will likely master the required code provisions of the

applicable sprinkler code. There may be a small window where the individual is

learning the code in the beginning or reviewing new code changes every so often, but

for the most part once they have mastered the code, navigational complexity is likely

irrelevant. However, an A/E firm designer likely designs more than just residential

sprinkler systems and may also work on other aspects of a building design, i.e. fire

alarm or MEP. In most instances, this individual will not master all aspects of the fire

sprinkler design and navigational complexity remains an issue. Coupled with the fact

88

that they have not mastered the sprinkler code, the A/E designer is likely subjected to or

required to utilize multiple codes in the design process. This suggests that the

navigational complexity within a given code is also coupled with navigational

complexity between codes.

Navigational complexity may reduce as familiarity with a code increases.

However, many jurisdictions skip cycles, meaning if they adopted the 2003

International Building Code (IBC) in 2004 they will skip the 2006 IBC and adopt the

2009 IBC in 2010. This basically compounds the increase in navigational complexity

for users within the given jurisdiction at onset of a new code’s introduction. It may

seem that learning changes to a code is not complicated, and oftentimes the changes to

a code are identified. The changes might also be published or presented at conferences;

however, for those not constantly focused on a specific design, the changes will not

manifest until the applicable code section is used or needed. Simply put, the A/E

sprinkler designer, from the example, will not be subjected to the changes within the

sprinkler code’s storage occupancy section until they need to design a storage sprinkler

system. They may only design one storage sprinkler system within any given code

cycle and therefore, mastery of that section is unlikely. Thus, navigational complexity

within that section will affect the designer. Whereas, the contractor’s designer will

likely quickly learn the changes to the residential section, and navigational complexity

will only briefly be an issue. Additionally, all other changes within the sprinkler code

are not even considered by the contractor’s designer.

89

4.3. Methodology

The intent of the case study is to quantify the effects of increasing navigational

complexity within a single code and then demonstrate how the navigational complexity

is compounded by any increase in navigational complexity within a referenced code.

The first step is to quantify increasing complexity over the years within a single code.

Although this has been done within previous research, this case study also looks at the

actual code provisions and describes why the navigational complexity is an issue. In

previous research, the numerical results indicated an increase in navigational

complexity, but they were not based on the framework of an actual design or the

content of the provisions. By studying the provisions for fire alarm systems within

elementary schools, it is possible to show and detail the issues with increasing

navigational complexity. Although there are many other appropriate design scenarios,

elementary schools existed in the past and will almost certainly continue to exist in the

future. Therefore, this scenario offers an example with which most code users can

relate.

The building codes that were utilized for the case study are: the 1967 through

1997 Uniform Building Code (UBC) and the 2000 through 2015 International Building

Code (IBC). The International Building Code was formed in part by the combination

of several other building codes, one of which was the Uniform Building Code. In

addition to the building codes used, the 2007 and 2013 National Fire Protection

Association’s National Fire Alarm and Signal Code (NFPA 72) were also reviewed.

In general, the building code dictates whether a fire alarm system or some

aspect of one is required in any given building. Also within the building code, the

90

requirements of the specific system are outlined, but the specific requirements can be

based on occupancy, building construction type, and height/area limitations among

other features. The “where required provisions” for fire alarm systems within building

codes usually have threshold limits for the various occupancy types, construction types,

or the height/area of a building. This means that fire alarm systems may not be

required under a certain threshold but eventually they are typically mandated. The use

of different levels of threshold for fire alarm systems is similar to the use of threshold

limits for fire sprinkler systems; although the limits are typically not the same.

However, the use of threshold limits for fire alarm and sprinkler systems varies slightly

from other aspects of life safety, which may be based solely on specific features.

Smoke control is an example, because regardless of an occupancy type it is required in

atriums. Understanding that there are thresholds to when a fire alarm system or any

other system that may be required is crucial, because a code user must examine the

specifics of any given scenario. A code use must review the content of the applicable

provisions to determine if a fire alarm system is required and what specific features of

the fire alarm system may be required for the given scenario.

The method of collecting and examining the applicable fire alarm system

requirements within the building codes is straightforward. The codes were reviewed

and the requirements for elementary schools were noted. This included listing the

applicable hierarchical structure of each code and identifying any cross references

within the applicable provisions. The results are shown in two forms: graphical and

numerical. The graphical results are to demonstrate the intricacies created by the cross

references and the numerical results are based on a previously developed metric. The

91

metric provides a quantifiable measure of increasing navigational complexity and is

shown below:


each class.


Weights


0


1.4


2.5



4.6


7.3


7

4.4. Results and Discussion

The 1967 UBC does not have any provisions regarding fire alarm systems, and

is only used as a reference point. It is relatively important to demonstrate that the

progression of fire alarm systems has evolved from essentially nothing. The 1970

edition has one provision with regards fire alarm requirements for elementary schools:

Fire Alarms

Sec. 8ll. Approved fire alarms shall be provided for all Group C

Occupancies with an occupant load of more than 50 persons. In every

Group C Occupancy provided with an automatic fire-extinguishing

92

system, the operation of such system shall automatically activate the

school fire alarm system [1].

The provision changed slightly in 1973 to include the requirement for an alarm

on the exterior of the building. The section number changed over the years but the

language in the provision existed as is until 1991. Below is the provision in the 1988

edition:

Fire Alarms

Sec. 809. Approved fire alarms shall be provided for all Group E

Occupancies with an occupant load of more than 50 persons. In every

Group E Occupancy provided with an automatic sprinkler or detection

system, the operation of such system shall automatically activate the

school fire alarm system, which shall include an alarm mounted on the

exterior of the building [2].

Although it is not readily apparent within the above provision, there are some

references to the Uniform Fire Code within the UBC, which suggests that the fire alarm

system would have indirectly been connected, through reference, to the National Fire

Alarm and Signal Code (NFPA 72) at the time, because NFPA 72 was referenced in the

Uniform Fire Code. However, by simply reading the provision requiring fire alarms in

Section 809, it is clear that there is an extensive amount of latitude given to what is

actually required within the fire alarm system. In terms of navigational complexity, it

is essentially non-existent at this point, with regards to fire alarm systems for

elementary schools. Below is the graphical representation of the “where required

provision” of the 1988 UBC:

93

Figure 14: Graphical Representation of the Hierarchical Structure of the 1988 UBC with regards to fire alarm system requirements

Since there are no cross references within Section 809, there is no navigational

complexity, which based on the metric, means the weight of navigational complexity is

zero. However, in the 1967 UBC there was no mention of fire alarm systems for

elementary schools, which means that it would also have a zero weight for navigational

complexity. The idea that a fire alarm system requirement exists in one edition and not

another is the main reasoning for the graphical representations. Figure 1 shows that

Section 809 exists in the 1988 edition, which is in contrast to the 1967 edition, which

has no fire alarm requirement. The importance of the graphical representations is

further demonstrated with examination of newer code editions.

After the 1988 edition the UBC started to undergo some fundamental changes to

the layout of the code, and some minor modifications were made to the “where required

provision”. Below is the actual language from the 1997 UBC and the graphical

representation:

305.9 Fire Alarm Systems.

An approved fire alarm system shall be provided for Group E

Occupancies with an occupant load of 50 or more persons. In Group E

Occupancies provided with an automatic sprinkler or detection system, the

operation of such system shall automatically activate the school fire alarm

system, which shall include an alarm mounted on the exterior of the

building.

94

See Chapter 10 for smoke-detection requirements.

For installation requirements, see the Fire Code. [3].

Figure 15: Graphical Representation of the Hierarchical Structure of the 1997 UBC with regards to fire alarm system requirements and the associated cross references

The language within provision 305.9 did not change from what had been used

since 1973 with exception of two cross references added at the end. The 1997 edition

of the UBC was the last edition, and the UBC along with several other codes

organizations joined and formed the International Code Council (ICC). The ICC

produces the IBC along with several other codes. There were some early competitors,

but the IBC is now the model code used throughout the majority of the United States.

There are differences in the way the UBC and IBC are written, but the primary

difference is that each occupancy listed in the IBC does not have a chapter that outlines

the specific requirements for that occupancy. Instead the requirements for each

occupancy type are listed in the various chapters. For example, the requirements for

fire protection systems in an elementary school are found within Chapter 9 Fire

Protection Systems, along with the requirements for all other occupancies and other fire

protection required features. This essentially creates navigational complexity, because

the information needed for each occupancy must be sought out and cannot be found

95

within a single chapter. However, this study only focuses on the navigational

complexity within the specific provisions requiring fire alarm systems.

The requirements for fire alarm systems in the IBC are located in Section 907:

Fire Alarm and Detection Systems. Within the hierarchical structure of Section 907 it

is sub-section 907.2: Where Required - new Buildings and Structures, that lists the

different occupancies and the various specific requirements for when a fire alarm

system is required for each occupancy. Sub-section 907.2.3: Group E sets forth the

requirements for elementary schools, which are part of a Group E occupancy. Below is

the actual 907.2 and 907.2.3 language and a graphical representation of the “where

required provisions” from the 2009 edition:

907.2 Where Required—new Buildings and Structures

An approved fire alarm system installed in accordance with the provisions

of this code and NFPA 72 shall be provided in new buildings and

structures in accordance with Sections 907.2.1 through 907.2.23 and

provide occupant notification in accordance with Section 907.5, unless

other requirements are provided by another section of this code.

A minimum of one manual fire alarm box shall be provided in an

approved location to initiate a fire alarm signal for fire alarm systems

employing automatic fire detectors or waterflow detection devices. Where

other sections of this code allow elimination of fire alarm boxes due to

sprinklers, a single fire alarm box shall be installed.

Exceptions:

96

1. The manual fire alarm box is not required for fire alarm systems

dedicated to elevator recall control and supervisory service.

2. The manual fire alarm box is not required for Group R-2 occupancies

unless required by the fire code official to provide a means for fire watch

personnel to initiate an alarm during a sprinkler system impairment event.

Where provided, the manual fire alarm box shall not be located in an area

that is accessible to the public.

907.2.3 Group E

A manual fire alarm system that activates the occupant notification system

in accordance with Section 907.5 shall be installed in Group E

occupancies. When automatic sprinkler systems or smoke detectors are

installed, such systems or detectors shall be connected to the building fire

alarm system.

Exceptions:

1. A manual fire alarm system is not required in Group E occupancies

with an occupant load of less than 50.

2. Manual fire alarm boxes are not required in Group E occupancies

where all of the following apply:

2.1. Interior corridors are protected by smoke detectors.

2.2. Auditoriums, cafeterias, gymnasiums and similar areas are protected

by heat detectors or other approved detection devices.

2.3. Shops and laboratories involving dusts or vapors are protected by

heat detectors or other approved detection devices.

97

2.4. The capability to activate the evacuation signal from a central point is

provided.

2.5. In buildings where normally occupied spaces are provided with a

two-way communication system between such spaces and a constantly

attended receiving station from where a general evacuation alarm can be

sounded, except in locations specifically designated by the fire code

official.

3. Manual fire alarm boxes shall not be required in Group E occupancies

where the building is equipped throughout with an approved automatic

sprinkler system installed in accordance with Section 903.3.1.1, the

notification appliances will activate on sprinkler waterflow and manual

activation is provided from a normally occupied location [4].

Figure 16: Graphical Representation of the Hierarchical Structure of the 2009 IBC with regards to fire alarm system requirements and the associated cross references.

The similarities in the language of the 2009 edition of the IBC and the 1988

edition of the UBC are evident, and it is basically the list of exceptions that has grown.

In general, with less than 50 occupants a fire alarm system is not required for an

elementary school. If there is a sprinkler system or fire detection it needs to be

connected to the fire alarm system; this has not change since 1988. There are two

98

references made within Section 907.2, NFPA 72 and Section 907.5. Additionally, there

are two cross references made in Section 907.2.3 that create navigational complexity,

907.5 and 903.3.1.1. Since the cross reference to 907.5 is made from within a sub-

provision that is not directly connected to the parent provision, it is considered

navigational complexity. However, both 907.2 and 907.2.3 make a cross reference to

Section 907.5, and although they are made to the same Section they are made from two

separate provisions, and must be calculated accordingly.

As noted previously, the 1988 edition had a zero weight for navigational

complexity based on the metric. In the 2009 edition “where required provisions”, 907.2

and 907.2.3, there are four instances of cross references to three different reference

points and one instance of an Intended Hierarchical Structure (IHS) blanket reference.

The blanket reference to Sections 907.2.1 through 907.2.23 is not considered to

increase navigational complexity, because the subordinate provisions are already

connected by the IHS of the code and thus, are omitted from Figure 2 and Table 1.

Based on the metric, the weight of navigational complexity for the “where required

provisions” in the 2009 IBC is 11.2, which is an increase from zero in the 1988 edition.

The results are shown below:

Table 18: Total weighted complexity of the "where required provisions" of the 2009 IBC

with regards to fire alarm systems in Elementary Schools

IBC Weighted Number of Occurrences in “where required provisions”

Total Weight Complexity Code


2012 7 0 0 0 4.2 11.2

99

The 2015 IBC has some modifications to the language and cross references

within the “where required provisions”; but not all of the changes were necessarily

made in the 2015 edition alone. Some modifications may have occurred in the 2012

revision cycle; however, since many jurisdictions skip editions, this is an example of an

actual scenario where the 2012 edition was skipped. The language and graphical

representation of the “where required provisions” for the 2015 edition are shown

below:

907.2 Where Required‒new Buildings and Structures

An approved fire alarm system installed in accordance with the provisions

of this code and NFPA 72 shall be provided in new buildings and

structures in accordance with Sections 907.2.1 through 907.2.23 and

provide occupant notification in accordance with Section 907.5, unless

other requirements are provided by another section of this code.

Not fewer than one manual fire alarm box shall be provided in an

approved location to initiate a fire alarm signal for fire alarm systems

employing automatic fire detectors or waterflow detection devices. Where

other sections of this code allow elimination of fire alarm boxes due to

sprinklers, a single fire alarm box shall be installed.

Exceptions:

1. The manual fire alarm box is not required for fire alarm systems

dedicated to elevator recall control and supervisory service.

2. The manual fire alarm box is not required for Group R-2 occupancies

unless required by the fire code official to provide a means for fire watch

100

personnel to initiate an alarm during a sprinkler system impairment event.

Where provided, the manual fire alarm box shall not be located in an area

that is accessible to the public.

907.2.3 Group E

A manual fire alarm system that initiates the occupant notification signal

utilizing an emergency voice/alarm communication system meeting the

requirements of Section 907.5.2.2 and installed in accordance with

Section 907.6 shall be installed in Group E occupancies. When automatic

sprinkler systems or smoke detectors are installed, such systems or

detectors shall be connected to the building fire alarm system.

Exceptions:

1. A manual fire alarm system is not required in Group E occupancies

with an occupant load of 50 or less.

2. Emergency voice/alarm communication systems meeting the

requirements of Section 907.5.2.2 and installed in accordance with

Section 907.6 shall not be required in Group E occupancies with occupant

loads of 100 or less, provided that activation of the manual fire alarm

system initiates an approved occupant notification signal in accordance

with Section 907.5.

3. Manual fire alarm boxes are not required in Group E occupancies


3.1. Interior corridors are protected by smoke detectors.

101

3.2. Auditoriums, cafeterias, gymnasiums and similar areas are protected

by heat detectors or other approved detection devices.

3.3. Shops and laboratories involving dusts or vapors are protected by

heat detectors or other approved detection devices.

4. Manual fire alarm boxes shall not be required in Group E occupancies


4.1. The building is equipped throughout with an approved automatic

sprinkler system installed in accordance with Section 903.3.1.1.

4.2. The emergency voice/alarm communication system will activate on

sprinkler waterflow.

4.3. Manual activation is provided from a normally occupied location [5].

Figure 17:Graphical Representation of the Hierarchical Structure of the 2015 IBC with regards to fire alarm system requirements and the associated cross references

Again, in the 2015 edition the “where required provisions” are 907.2 and

907.2.3, but in the 2015 edition there are six separate instances of cross references and

one instance of an Intended Hierarchical Structure (IHS) blanket reference. Unlike the

need to account for cross references to the same provision made from separate

102

provisions, repeated cross references within a single provision are not counted multiple

times. The justification for this is that the code user will likely read the entire provision

before moving to any references, which is specifically evident in provisions with listed

exceptions, such as 907.2.3. Based on the metric, the weight of navigational

complexity for the “where required provisions” in the 2015 IBC is 14, which is an

increase from 11.2 from the 2009 edition.

Table 19: Total weighted complexity of the "where required provisions" of the 2015 IBC

with regards to fire alarm systems in Elementary Schools

IBC Weighted Number of Occurrences in “where required provisions”

Total Weight Complexity Code


2015 7 0 0 0 7 14

Figure 4 shows the total weighted complexity within the “where require

provisions” for an elementary school fire alarm system over the past 60 years. In the

last 20 years the trend shows that the navigational complexity slightly increases every

few revisions cycles. This matches other aspects of the building code and was

identified to be typical in previous research. Most revisions are minor changes and are

based on new information being added. Although there was a significant jump in

navigational complexity between 1988 and 1991, it was likely warranted. The

language prior to 1991 was without any cross references and was vague. Although a

fire alarm system was required, the specifics were not given and there was no

indication where the information was to be found. By including the cross references,

direction was given to the additional specific requirements for fire alarm systems

located in other areas of the code or in completely separate codes.

103

Figure 18: A graph showing the increase in navigational complexity over the past 60 years.

The subjectivity of navigational complexity can make describing why

navigational complexity is an issue difficult. A simple answer to the question of why

navigational complexity is an issue, is that it hinders the user’s ability to progress

through the IHS of a code. Although it is not necessary that a code user follow a code

chronologically at all times, in general, the provisions have been ordered and arranged

within a code based on some form of logical progression. Thus, cross references

interfere with the logical progression and create the ability for mistakes or

misinterpretations to occur. Although mistakes and misinterpretations can lead to

unsafe designs, which is a major concern, they can also lead to over-engineering or

underutilization. Underutilization or mistakes can occur regardless of a cross reference,

but cross references increase the chance. A cross reference made within a provision

forces a code user to move away from their current position, retrieve the necessary

information within the cross reference, and return to the starting point.

104

A simple example of why navigational complexity is an issue is in exception 2

of Section 907.2.3:

2. Emergency voice/alarm communication systems meeting the requirements of

Section 907.5.2.2 and installed in accordance with Section 907.6 shall not be required

in Group E occupancies with occupant loads of 100 or less, provided that activation of

the manual fire alarm system initiates an approved occupant notification signal in

accordance with Section 907.5.

The language within the exception permits the code users to avoid using an

Emergency voice/alarm communication system, described in Section 907.5.2.2, in an

elementary school with less than 100 occupants. However, it does require the

installation of a fire alarm system, described in Section 907.5, for elementary schools

with an occupant load between 50 and 100. The issue in this case is that 907.5.2.2 is

actually within Section 907.5, and the IHS of 907.5 makes it difficult to differentiate

the nuances of the two system types. This means that it is possible to over-engineer the

required system by installing an Emergency voice/alarm communication system instead

of a fire alarm system, which would still be compliant, but not required. This is a

simple example and those trained in using the building code likely understand the

nuances, but it is also relatively easy to see why navigational complexity is an issue in

this case.

Another important aspect that should be noted about exception 2 of Section

907.2.3 in the 2015 edition is that in the 2012 edition the threshold was at 30 occupants.

However, for over 30 years prior to the 2012 edition the threshold for a fire alarm

system in an elementary school was set at 50 occupants. Additionally, instead of just a

105

fire alarm system being required for elementary schools with an occupant load greater

than 30, which had also been required for past 30 years, the provision was modified to

require an Emergency voice/alarm communication system. An Emergency voice/alarm

communication system is essentially a fire alarm system combined with a robust

public-address system. As shown in the example above section 907.2.3 was modified

again in 2015, so that no system of any type is required for an occupant load less than

50. For an occupant load between 50 and 100 only a fire alarm system is required, but

for an occupant load greater than 100 an Emergency voice/alarm communication

system is required.

The significance of the modifications to Section 907.2.3 are two-fold. First, in

the 2015 edition there are four cross references, while in the 2012 edition there are only

three. Thus, in principle, the navigational complexity increased within that provision.

The second point of significance is that Section 907.2.3 in the 2015 edition essentially

reverted back to what had previously existed for over 30 years. The 50-occupant limit

was reestablished, which means the language was modified, likely compounding the

added navigational complexity. However, it should be noted that many jurisdictions

have been using the odd year code editions (2003, 2009, 2015) and if this is the case,

would not have been affected by the layer of change in the 2012 edition, but only the

changes between 2009 and 2015 that were described above.

The increase in navigational complexity within a few provisions of a code is

easily shown, but may not provide sufficient evidence that navigational complexity is

an actual issue for some code users. Additionally, providing a simple example and

explaining why navigational complexity within a few provisions is an issue may also

106

not provide sufficient evidence, because navigational complexity is subjective.

However, it is difficult to defend that navigational complexity created by a cross

reference between two different codes, developed by two different organizations is not

an issue. Demonstrating the compounding issues between the IBC and NFPA 72 was

the second part of this study.

Within Section 907.2 of the 2009 and 2015 IBC editions, NFPA 72 is

introduced via a cross reference. This cross reference in itself adds some complexity,

as suggested in Table 1 and Table 2; however, quantifying compounding navigational

complexity in general is difficult because it can vary for most scenarios. The subjective

nature of navigational complexity can make some cross references have more or less

impact on individual users, but in some cases the navigational complexity is

compounded by changes or modifications to the referenced code, which occurs

regardless of a user’s experience with said code. For example, the 2007 NFPA 72 was

being used at the onset of the 2009 IBC. The 2007 NFPA 72 did not have a specific

chapter on Emergency voice/alarm communicating systems, but this chapter was part of

the 2013 edition, which would have been used at the onset of the 2015 IBC. Thus, any

navigational complexity within the new chapter of NFPA 72 or even within the code in

general was likely compounding the added navigational complexity within the IBC.

Graphically it is hard to capture an increase in navigational complexity without using a

specific scenario and a complete examination of the code based on that scenario.

However, because Chapter 24 was not part of the 2007 edition, simply adding Chapter

24 to the graph represents some level of additional navigational complexity.

107

Figure 19: Graphical Representation of the Hierarchical Structure of the 2015 IBC with additional compounding navigational complexity of NFPA 72

Graphing navigational complexity to compare an increase between two editions

can be insightful. As seen in Figure 5, more navigational complexity was added to the

2015 IBC because of modifications to NFPA 72. The changes between the 2007 and

2013 NFPA 72 were somewhat drastic. Most changes within a code are not drastic, but

because so many cross references exist in the IBC, to a large number of other codes,

there are likely always a few that have recently undergone drastic changes. Therefore,

this example likely represents an actual scenario that occurs within the IBC during any

given revision cycle. Regardless of the changes that must be captured during revisions

cycles of the IBC there is also the issue of changes during the three-year term. For

example, the 2013 NFPA 72 is referenced by the 2015 IBC, but the new 2016 NFPA 72

is released well before the 2018 IBC. This means there are often instances where some

ambiguity exists. Many fire alarm installers will immediately start using the new code,

while building code officials stay with the previous edition.

108

Switching from an old code to a new code typically takes time and the adoption

process involves individuals from local government. As discussed previously, this is

the reasoning behind why many jurisdictions skip cycles. There are often minor

modifications to each code that have some impact. For example, the 2016 NFPA 72

added a provision to allow the use of non-listed speakers in certain situations to

increase the intelligibility level. If a jurisdiction has not adopted the 2016 edition, then

this would not be permitted, and although it seems like a relatively simple issue it is not

always straightforward. Picking and choosing what provisions from a new code edition

should be used without adopting the new edition, opens up the possibility for

unforeseen problems. However, not using the most up-to-date code is questionable in

itself, and is the reasoning behind why some government agencies specifically

reference only the most up-to-date editions.

The requirements for a fire alarm system within an elementary school have

changed greatly over the years. Early systems had smoke detection throughout and

were provided with horns to alert occupants. Figure 6 would have been a typical layout

in the 1980’s, with smoke detection in the classrooms, a horn in the corridor, and a horn

on the outside of building. As the requirements morphed, the use of strobes was

introduced and eventually all occupiable areas of the building were required to have

some form of notification. Some of the changes over the years are more obvious than

others, but the most obvious is the shift away from horns to the use of speakers. Figure

7 shows a current typical layout that is provided with combination speaker strobe

devices in almost all areas, smoke detection only in the corridor and without an outside

109

notification device. Since most fire alarm systems are now connected to a monitoring

company the need for sounding an alarm outside of the building is no longer necessary.

The use of speakers allows for the ability to relay messages throughout a

building in an emergency. Although most schools already had a public-address system,

the PA system would not always function in an emergency, i.e. power failure.

Combining a fire alarm system and voice communication system, provides the ability

to alert occupants with pre-recorded messages, such as in a fire drill or in an emergency

lock-down situation, all in addition to the normal fire alarm signal. These features are

not new concepts and have been used in high-rise buildings for an extended period of

time, but are relatively new to elementary schools. Some of these modifications to the

fire alarm requirements for elementary schools are the result of tragic events. Similar

to other tragic events, such as the Station Night Club fire, which prompted changes to

the building codes, tragic events at schools have also prompted changes to the building

code. An example of this is the requirement for Emergency voice/alarm

communication systems in schools with more than 100 occupants.

110

Figure 20: 1980's Fire alarm system in an elementary school

Figure 21: 2015 Fire alarm system in an elementary school

111

There are many parts and pieces that have been added to building codes over the

years, some of which are based on incidents that have occurred, while others are new

exceptions to when a provision is applied. Similar to other areas of the building code,

not all of the changes to the fire alarm system requirements for elementary schools

resulted in added navigational complexity or created navigational complexity with a

cross reference. The majority of the changes is in the form of added language and

exceptions to rules. This is observed by comparing the “where required provisions” of

the 1980’s, containing four lines of code in a single provision, and comparing it with

the thirty plus lines of code over two provisions in the current code. The addition of

new information or provisions can be difficult to quantify; however, as shown with the

increase of navigational complexity through the years, cross references typically creep

into new information being added. These cross references add navigational

complexity, but fortunately it is rather straightforward to quantify navigational

complexity. As such, increasing navigational complexity can be identified, which may

make it possible to reduce unnecessary navigational complexity in the future.

4.6. Conclusion

Navigational complexity is subjective and the changes to the provisions within

new editions will affect users differently. The example used in this study is relatively

simple, and the fire alarm system would also be a very small piece of the overall design

and scope of an elementary school project. However, it provides a real example of

increasing navigational complexity as well as an explanation for why it can become an

issue. Not all aspects of a code change over the years, but many do, hence why new

112

editions come out every few years. There may be only small changes to provisions, but

as shown navigational complexity is additive and compounding. The navigational

complexity found within the fire alarm provisions of the building code is added to the

navigational complexity found within the cross referenced codes. Therefore,

navigational complexity created by cross references hinders the logical progression

through one code or even multiple codes, which is why navigational complexity is an

issue.

The project that was the basis for this case study also involved other aspects of

fire and life safety and the associated navigational complexity. For example, the

combined area of the addition and original building was over the area threshold for

requiring a sprinkler system in a building of Type V-B construction. Although a

sprinkler system is not required in a building with a Group E occupancy that is less than

12,000 square feet, the maximum area permitted area for a Type V-B building, Group E

occupancy, without a sprinkler system is only 9,000 square feet. This prompted the

need to create a fire wall between the addition and original building, which essentially

created two separate buildings. The need for a fire wall introduce additional code

provisions and the subsequent navigational complexity associated with the provisions.

With regards to the fire alarm system the State did not push the issue any further than

suggesting a more robust system and the school proceeded with a simple fire alarm

system, as required in the earlier code.

113

References

1. Uniform Building Code. Whitter, Calif. (5360 South Workman Mill Rd., Whitter 90601: International Conference of Building Officials, 1970.





114

CHAPTER 5: REACHING THE COGNITIVE LIMIT

Abstract

Building codes are considered too complex by many practicing engineers, but

with little scientific proof or quantitative evidence. This research hypothesizes that it is

possible for codes to become too complex and that there may be instances where the

cognitive limit of navigational complexity within any given code is exceeded.


referencing and other unintended structural features of a code. Additionally,

navigational complexity has been previously shown to be increasing in many

commonly used codes. Nevertheless, navigational complexity does not appear to have

reached a level where all code users agree a code is too complex and refuse to use it.

The likelihood of a code becoming so complex that users refuse to use it seems

farfetched, but the likelihood of a code becoming so complex that mistakes are

unrecognized is plausible. The existence of a cognitive limit of navigational

complexity may provide the necessary scientific proof for justifying modifications to

building codes.

5.1. Introduction

Today’s building codes are much more complex than their predecessors, and

this has been suggested within literature. Navigational complexity, a specific form of

complexity within building codes, has increased in many codes, if not all, over their

respective histories, and this has been shown in Chapters 1-3 of this dissertation.

115


referencing and other unintended structural features of a code. Although there have

been extensive increases in the navigational complexity of some codes, it appears that

the threshold tolerance of overall navigational complexity is very high. The total

amount of navigational complexity does not appear to have exceeded a limit that most

codes users can comprehend. However, it may be possible that code users are

subjected to successive cross referencing that may be beyond the cognitive limit.

5.2. Background

To identify the existence of an exact quantity of navigational complexity within

a code that could be considered the cognitive limit would require the complete

understanding of navigational complexity of a specific code. It would also be highly

subjective and difficult to verify. Nonetheless, the limit of successive cross referencing

that a user can comprehend or manage is likely finite, and will likely vary between code

and code user. The results may also vary with experience and familiarity with the code,

among other things, but would likely fall within a close range. The best way to

estimate the limit is through testing. The results of research into the working memory

and cognitive limit of humans working memory on similar tasks can also provide

guidance.

Code users reading a code start at one point and continue to the next points until

they have the information they need; however, this can be done one of two ways,

chronologically or by a reference. The hierarchical structure of almost all codes

consists of the numbered chapters, sections and provisions within the document, and

116

these can be considered the intended hierarchical structure (IHS). This IHS forms the

natural chronological path that a code user steps through. Since moving in a straight-

line is typically not complex, with regards to moving from one point to another, then it

can be assumed no navigational complexity exists as a result of the IHS (chronological

steps of a code). This assumption may be too broad, but has several key points. The

first being, that most code related grievances within literature are based on specific

provisions and have little to do with the order of information. Secondly, many codes

have been re-organized in the past, and literature shows that the grievances continue.

Thus, the assumption was used, and all navigational complexity is considered to be the

result of cross references.

There has been extensive research on the working memory and the cognitive

limit of humans over the past fifty years [1]. This work has repeatedly shown that there

is a limit to the working memory of humans and although it may vary slightly

depending on the situation, it typically falls in the 3-5 “chunk” range. The “chunk”

range refers to pieces of information, such as sentences or a string of numbers. Now it

must be understood that this is referring to the working memory, or short-term memory,

and is not the same as long term. Long term memory would refer to those things that

have been committed to memory. This is important because some code users have

committed provisions, and in some instances the references made within the provisions

to memory. However, the extensiveness of most codes and continual updating of codes

makes committing more than a few provisions to memory challenging.

Literature has indicated that humans are cognitively limited to tracking about

four objects, and that traveling within cities from point A to point D, with two

117

intermediary way points - B & C, is limited by their visual working memory [3].

Postulating that this cognitive limit can be correlated to cross references within building

codes is practical, and is the theory of this investigation. Although the exact limit may

vary between users, the authors assumed a single limit exists and proceeded to

determine and identify successive cross references and any successive cross references

of two or more intermediary way points. This may be a first step to identifying ways to

reduce the complexity of building codes.

The existence of navigational complexity has been confirmed within previous

research. However, the existence of successive cross references has, to this point, not

been confirmed. For practical purposes, it is important to relate the effects of cross

referencing to a universal concept. An analogy is the universal concept of

transportation. Below is a small sample comparison of the variety of cross references

and how they can be related to moving around a city:

The general assumption is that the code user would be reading a code in

chronological order, and any cross reference would be a “detour” or deviation from the

normal path, but the user would be required to return to the original path.

Provision A references Provision B – This would be similar to stopping

along one’s current route home. It is relatively easy.

Provision A references Chapter B – This would be like running an errand

in the opposite direction of the route home. Not overly complicated, but

can be, depending on the situation.

118

Provision A references Code B – This would be like going to a different

city before going home from work. Very complicated and time

consuming.

The examples are very general, but they do show both that a single reference

can be complex and that several successive cross references can significantly increase

the level of navigational complexity. Thus, when using the simple analogy of traveling

to compare the effects of references, it becomes clear that successive cross referencing

can become complex for code users. Moving provision to provision is simple within

the IHS, but when it is required to move to a separate provision the navigational

complexity increases.

5.3. Methodology

The data were collected by examining selected sections of commonly used

codes and specifically by “mapping” them. This consisted of listing all the provisions

within the section, identifying any references made within the provisions, and

following the references to determine if they were terminal or continued. Terminal

provisions are provisions that do not have any references or are at the end of the IHS of

a section of code. If the second references were not terminal then this sequence was

considered beyond the cognitive limit. Figure 22 shows two examples of successive

cross references considered within the cognitive limit and an example of when

successive cross references exceed the cognitive limit.

Visually, the successive cross references do not look complicated, but the way a

code’s hierarchical structure works, the user must go back to the starting provision after

119

reaching a terminal reference or proceed to the next sequential provision. Therefore, if

the universal concept of transportation is used, the sequence of cross references would

be like driving to three cities before going home. Certainly, that seems complicated

and to add more emphasis, each code must be purchased and consideration to the cost

would be necessary. The next sequential provision, as shown in Figure 22, would be

provision B. Although there may be some differentiation between returning to the

starting provision (provision A) or proceeding to the next sequential provision

(provision B), it is assumed they are the same.

Figure 22: Examples of successive cross references within and outside the estimated cognitive limit of code users

For data collection purposes, the references were listed as one of the following:

Code Reference, Chapter Reference, Outside Section Reference, and Inter-Section

Reference. An example of each type of reference from NFPA 101 [2] is shown below:

Code Reference -

9.1.2 Electrical Systems.

120

Electrical wiring and equipment shall be in accordance with NFPA 70,

National Electrical Code, unless such installations are approved existing

installations, which shall be permitted to be continued in service.

Chapter Reference -

9.6.3.5.4

Visible signals shall not be required in lodging or rooming houses in

accordance with Chapter 26.

Outside Section Reference -

9.4.1 General.

An elevator, other than an elevator in accordance with 7.2.13, shall not be

considered a component in a required means of egress but shall be

permitted as a component in an accessible means of egress.

Inter-Section Reference -

9.3.3 Acceptance Testing.

Acceptance testing shall be performed by a special inspector in

accordance with Section 9.13.

A complete examination of each code would be necessary to determine all

instances of successive cross referencing within the code; however, the technique can

be applied locally or globally. Thus, for the simplicity of demonstrating the existence

of successive cross referencing within the various codes, only individual sections were

used.

There are some caveats as to how the data were collected, but primarily only

two are of significance for this research. The first being any references within a

121

provision to sub-provisions directly below were omitted. This basically omitted

references that were already connected by the IHS. See example below:

9.1.3 Emergency Generators and Standby Power Systems.

Where required for compliance with this Code, emergency generators and

standby power systems shall comply with 9.1.3.1 and 9.1.3.2 [2].

Although it is not always true, in general the chronological progression from

provision to sub-provision and back is necessary and therefore, any reference to

immediately connected provisions is considered to not add navigational complexity. A

complete examination of the language and use of each subordinate reference would be

necessary to determine whether or not any navigational complexity is added, but may

be necessary regardless.

The second caveat is that some occurrences of blanket references to multiple

chapters were made by the provisions, and their references were counted as single

references. See example below:

9.6.2.10.2

Where automatic smoke detection is required by Chapters 11 through 43,

smoke alarms shall not be used as a substitute [2].

These references were not initially counted as a single reference because some

would, in fact, be to multiple chapters. However, by inspection it can be determined

that some chapters within the list are reserved chapters and do not contain any

provisions, some references are not applicable and finally, references back to the

chapter from which a provisional reference came from would not add any navigational

complexity and could be also omitted.

122

There is almost certainly a differentiation in the complexity between the four

types of successive cross references used. Although, a variation in complexity may

exist between reference type, the cognitive limit is considered to not be affected.

Literature indicates that the limit is still probably within the 3-5 “chunk” range.

Therefore, the justification that three successive cross references as the cognitive limit

of code users is based on the average four “chunks” of information. Below is an

example of an instance of four successive cross references from the 2015 IBC [8]. This

provides an example as to how the data were collected, and how complicated even

individual sections of codes can become.

405.4.3 Elevators.

Where elevators are provided, each compartment shall have direct access

to an elevator. Where an elevator serves more than one compartment, an

elevator lobby shall be provided and shall be separated from each

compartment by a smoke barrier in accordance with Section 709. Doors

shall be gasketed, have a drop sill and be automatic-closing by smoke

detection in accordance with Section 716.5.9.3.

716.5.9.3 Smoke-Activated Doors.

Automatic-closing doors installed in the following locations shall be

automatic-closing by the actuation of smoke detectors installed in

accordance with Section 907.3 or by loss of power to the smoke detector

or hold-open device. Doors that are automatic-closing by smoke detection

123

shall not have more than a 10-second delay before the door starts to close

after the smoke detector is actuated:

1. Doors installed across a corridor.

2. Doors that protect openings in exits or corridors required to be of fire-

resistance-rated construction.

3. Doors that protect openings in walls that are capable of resisting the

passage of smoke in accordance with Section 509.4.

4. Doors installed in smoke barriers in accordance with Section 709.5.

5. Doors installed in fire partitions in accordance with Section 708.6.

6. Doors installed in a fire wall in accordance with Section 706.8.

7. Doors installed in shaft enclosures in accordance with Section 713.7.

8. Doors installed in refuse and laundry chutes and access and

termination rooms in accordance with Section 713.13. Automatic-closing

chute intake doors installed in refuse and laundry chutes shall also meet

the requirements of Sections 716.5.9 and 716.5.9.1.1.

9. Doors installed in the walls for compartmentation of underground

buildings in accordance with Section 405.4.2.

10. Doors installed in the elevator lobby walls of underground buildings

in accordance with Section 405.4.3.

11. Doors installed in smoke partitions in accordance with Section

710.5.2.3.

907.3 Fire Safety Functions.

124

Automatic fire detectors utilized for the purpose of performing fire safety

functions shall be connected to the building's fire alarm control unit where

a fire alarm system is required by Section 907.2. Detectors shall, upon

actuation, perform the intended function and activate the alarm

notification appliances or activate a visible and audible supervisory signal

at a constantly attended location. In buildings not equipped with a fire

alarm system, the automatic fire detector shall be powered by normal

electrical service and, upon actuation, perform the intended function. The

detectors shall be located in accordance with NFPA 72.

The example shows that successive cross references do exist, but stops at NFPA

72 for simplicity. NFPA 72 has 17 references to other NFPA documents. As noted

previously, it is important to show how navigational complexity can be affected by a

single reference. The number of provisions connected to any given provision through

cross references can be extensive.

5.4. Results and Discussions

The results are shown in two portions, numerical and graphical. The graphical

results are shown to help visualize the complexity of even small sections of code. Two

sections from each of the following codes were examined: ACI 318 – Building Code

Requirements for Structural Concrete; 2014 Edition, NFPA 101- Life Safety Code ®;

2015 Edition, and the International Building Code (IBC); 2015 Edition. Although

complexity is not limited to these codes, they are commonly used codes and are a

familiar example for most code users.

125

5.4.1. Numerical Results

A complete examination of each code would be necessary to determine all

instances of excessive cross referencing within the respective codes. However, for

statistical sampling purposes to demonstrate the existence of successive cross

references beyond the postulated cognitive limit, two sections from each code were

used and provide more than adequate data. The results are shown in Table 20 for the

ACI 318, Table 21 for NPFA 101 and Table 22 for the IBC.

Table 20: The number and type of references within selected ACI 318 sections

ACI‐318# of

Provisions*

Total # of

References

Code

References

Chapter

References

Outside

Section

References

Inter‐

Section

References

Section 9.2 15 9 0 3 6 0

Section 13.4 11 9 0 1 7 1 Table 21: The number and type of references from selected sections of NFPA 101

NFPA 101# of

Provisions*

Total # of

References

Code

References

Chapter

References

Outside

Section

References

Inter‐

Section

References

Section 7.4 14 6 4 0 1 1

Section 9.7 14 9 2 2 5 0 Table 22: The number and type of references within selected IBC sections

IBC# of

Provisions*

Total # of

References

Code

References

Chapter

References

Outside

Section

References

Inter‐

Section

References

Section 903.3 23 18 8 0 7 3

Section 1003 12 13 0 1 12 0

*The number of provisions is an approximation, because some high-level

provisions do not provide any information but are used instead as section headers. The

number of provisions was estimated by counting each numbered provision, regardless

of content.

126

The numerical results in the tables show that there are extensive amounts of

cross referencing within the sections of the three chosen codes, and that there is more

than one reference for every two provisions. However, the results so far only represent

single cross references and would not yet signify instances beyond the cognitive limit.

By simple inspection of the References Section of each code, it is clear that at some

point within each code there is a reference to another code. Therefore, any reference to

a code will almost certainly result in another code reference. Consequently, this would

result in more than three successive cross references (two intermediary way points),

and based on the postulated assumption, would be outside the cognitive limits of code

users. Similarly, references to chapters will almost always result in more successive

cross referencing and create more than two intermediary way points.

The existence of the cognitive limit being exceeded by cross references to codes

and chapters is not surprising. The importance of references to various codes likely

outweighs the complexity they add and would therefore be unavoidable. However,

there are instances when code references can be made to specific portions of code,

which can be described as provisional code references. The following provision from

the IBC is an example:

910.4.6 Control wiring

Wiring for operation and control of mechanical smoke removal systems

shall be connected ahead of the main disconnect in accordance with

Section 701.12E of NFPA 70 and be protected against interior fire

exposure to temperatures in excess of 1000°F (538°C) for a period of not

less than 15 minutes [5].

127

Provisional code references create less complexity and would be similar to

driving to a specific address in another city versus just knowing what city to be in.

Modifying code references to provisional code references may reduce complexity, but

there may only be a limited number of opportunities.

Cross references to entire chapters are also typically unavoidable. Based on the

results, there are a limited number of chapter references in the sample codes and it is

likely that they are necessary. However, as shown by the number of outside section

references within the results, there are many times when specific references to other

chapters are made and modification of chapter references should not be completely

discarded. Outside-section cross references and inter-section cross references almost

certainly represent the majority of the avoidable navigational complexity within codes,

and each must be examined individually.

Multiple references can be correlated to going to the store, and then going to

another store because the first store did not have what is needed. However, to fully

understand the impact of a cross reference with regards to navigational complexity,

each individual reference must be examined to determine whether or not the cross

reference itself has a cross reference. This either confirms or denies that the sequence

of cross references is beyond the cognitive limit of code users. The results from the

previous selected sections were used and each reference provision was examined,

checking to see if another reference existed or if it was a terminal reference.

Table 23: The selected codes provisions (ACI 318, NFPA 101, and the IBC) and the type

and quantity of cross references within them.

128

Code and

Section

# of

Provisions

with

References

Total # of

References

Outside

Section

References

Inter‐

Section

References

Number of

References

Exceeding

Limit

ACI 9.2 6 6 6 0 3**

ACI 13.4 2 8 7 1 4**

NFPA 9.7 2 2 1 1 2

NFPA 7.4 3 5 5 0 5

IBC 903.3 8 10 7 3 10

IBC 1003 3 12 12 0 11

**The second reference in one provision in section 9.2 and two in section 13.4

of the ACI 318 were to codes. References to codes were omitted as necessary from the

first references but were counted in this second set. The reasoning behind this was that

the applicability of a chapter is unknown after the first references. It does not

significantly alter the results but should be noted.

Table 23 shows the number of successive cross references in each of the

selected sections. The compiled results show that there are extensive amounts of

references that are beyond the estimated cognitive limit of code users. However,

determining how to fix the issues can be ambiguous with the numerical results alone.

5.4.2. Graphical Results

The numerical results confirm that successive cross references exist, but

visualizing them can be difficult. Furthermore, the navigational complexity associated

with cross referencing can be greatly underestimated when looking at the numerical

results alone, because it does not capture the entire system. As such, it is necessary to

incorporate graphical representations with the numerical results. Navigational

129

complexity can be exacerbated by provisions that are comprised with multiple layers of

sub-provisions. Provisions with multiple layers of sub-provisions are known as

Extensive Hierarchies. Extensive hierarchies can make visualization difficult;

however, it is necessary to include the IHS within the graphs, because they demonstrate

the whole structure. This part of the results uses an example of successive cross

references found in one of the selected sections from the ACI 318 and provides the

results in graphical form. The results not only show that the postulated cognitive limit

is exceeded within codes but also that navigational complexity can quickly become

overwhelming.

The example starts with provision 9.2.4.1 of the ACI 318 and Figure 23 shows

that based on the language within the provision and associated referenced provisions,

three successive cross references exist. However, this in an over simplification because

it does not include any of the IHS of the code.

Figure 23: A simplified graph of a successive cross reference within the ACI 318

130

Within Figure 23 the arrows point in the direction of the references being made.

In general, it is not necessary to differentiate the direction of reference, but in situations

where circular-references may exist it can be helpful. Additionally, once the IHS is

added to the graph, the order of references must be differentiated. To demonstrate the

effects of navigational complexity it is necessary to show a representation of the

example without simplification, i.e. showing all the references within the provisions.

As a first step, the IHS of the first referenced provision (16.4) is added.

Figure 24 is a representation of the same example with the IHS of reference

section 16.4 added. This does not include any other references from within the sub-

provisions of 16.4, with exception to 16.4.3.2 which references section 21.2 and was

part of the original example sequence. The complexity added by a single reference

appears to be increasing. As a second step, all other cross references with the IHS of

section 16.4 have been added and are shown in Figure 25.

131

Figure 24: An example successive cross reference with IHS added from only one reference

132

Figure 25: An example with references added to sub-provisions of section 16.4

In principle, it is possible to extend the graph in Figure 25 to included

everything, which would extend to the last provision of the IHS within any given

sequence. The only other time the graph would not grow any further would be if the

referenced provision was a terminal provision, i.e. does not reference anything.

However, it would quickly fill up a single page and be impossible to read. The

compounding complexity can be understood without more example.

133

By simple inspection it becomes clear that the ACI 318 is filled with successive

cross references. Even the instances where there are only two successive cross

references are likely contributing to navigational complexity. Differentiating between a

reference to a provision that would already be part of the IHS and those that are not is

difficult. Figure 25 shows that both IHS and references appear to be creating a

complex system that intertwines the two. This suggests it may be important to examine

cross references to determine if they are actually needed. Since the IHS connects

provisions, additional cross references may not always be warranted. This can be

slightly confusing since the IHS is generally not considered navigationally complex.

However, the extensive hierarchies are almost certainly contributing factors to the

overall complexity of using a code, which can be seen by the 25 additional provisions

added because of the reference to section 16.4 in Figure 25.

Creating more specific references could limit the amount of provisions included

within the “network” created. For example, if it were determined that the reference in

section 9.2.4.1 could be made to sub section 16.4.3.2 instead of 16.4 then all of the IHS

within 16.4 could be eliminated from the graph, which would make the example look

like Figure 26.

134

Figure 26: An example of the result of a modification the reference in order to reduce overall

complexity.

Figure 26 is still a generalization because it does not include the IHS of section

21.2, but if section 21.2 is as complex as 16.4 the reduction in the “network” would still

be cut in half by modifying the reference from section 9.2.4.1 to 16.4.3.2. Although the

successive cross reference may still exist in this example, the example could be

changed so that section 9.2.4.1 references a terminal provision within section 16.4, and

would therefore eliminate the successive cross reference. This suggests that if cross

references can be modified to specific provisions then the complexity of the sequence

can be reduced.

5.5. Conclusion

Navigational complexity can be necessary; however, it is not always necessary

and this research has shown that many cases may be avoidable and may stem from a

135

build-up of minor cross referencing within single sections. The exact cognitive limit of

cross referencing has not yet been measured, but if the assumption that moving around

cities can be correlated to moving around codes, then the limit is likely two

intermediary way points. There are instances of successive cross references beyond the

assumed cognitive limit and by graphing the cross references and the intended

hierarchical structures associated it is possible to visualize the navigational complexity.

Although the extent to which navigational complexity contributes to the overall

complexity of codes is not known, this research shows that it is a contributing factor

and it likely needs to be addressed. The research has also shown that more specific

reference results in a less complex sequence “network”, by reducing the IHS involved.

References

1. Cowan, Nelson. "The magical mystery four: How is working memory capacity limited, and why?." Current directions in psychological science 19.1 (2010): 51-57.


3. Gallotti, Riccardo, Mason A. Porter, and Marc Barthelemy. "Lost in transportation: Information measures and cognitive limits in multilayer navigation." Science advances 2.2 (2016): e1500445.

4. National Fire Protection Association. NFPA 13: Standard for the Installation of Sprinkler Systems. National Fire Protection Association, 2016.


136

CHAPTER 6: ABANDONING OLD CODES

Abstract

If a new building code was developed that only served simple structures it may

be possible to create an online tool that can completely auto check simple designs. The

use of computer software and programs to simplify complex problems within the built

environment is hardly bulletin. Additionally, a Computable Building Code (CBC), a

code that can be implemented into software package to use in an Automated Code

Checking (ACC) process, is not a new concept. However, the implementation of

software programs for ACC have been limited, despite the significant amounts of

research conducted. Creating the ability to auto check building codes is not trivial, but

doing so could revolutionize the built environment. There is complexity that exists in

current building codes that hinder the ability of software programs to completely auto

check a design. Rather than attempting to address the complexity within building codes

that has plagued the industry for years, it may be more appropriate to create a new

building code specifically for the use in an online auto checking tool.

6.1. Introduction

The benefit of complete design Automated Code Checking (ACC) may not be

completely understood; however, extensive research has been done on the effects of

building codes and many believe that enforcement is the most significant issue in the

construction industry [1]. Also within the realm of enforcement, is the time it takes to

get a project permitted, which is also the subject of extensive research [2]. ACC would

137

likely reduce issues with enforcement and would almost certainly reduce the permitting

time, which would revolutionize the construction industry. However, combination of

organization structure and difficult to compute provisions in the current building codes

appear to be the road block preventing complete design ACC from becoming a reality.

With regards to complexity and nature most plants and animals have adapted

over time to their surroundings, and this is no different for building codes. Building

codes, as we know them today, have generally evolved over the past 100 years. Codes

have adapted, and similar to animals evolving the changes are relatively minor. The

incremental changes from edition to edition are not often noticeable to the untrained

user, but over extended periods of time even untrained users can detect differences. An

example would be fire sprinklers, which in early codes were not required in a variety of

occupancies, but over time more and more occupancy types have been required to

install them.

It is the opinion of some practicing engineers that codes are the sum of reactions

to unfortunate events, which may have some merit [3]. Catastrophic events that have

resulted in changes to codes can be considered part of the building code evolution [4].

Even knee-jerk reactions to serious events are evolution. Similarly, natural disasters

have provided the justification for having building codes in some areas ([5], [6]). The

importance of building codes is not generally questioned in literature. The typical

sentiment being, “In the absence of building codes, the consumer might be forced into a

trade-off between cost and dwelling and level of risk from safety and health points of

view [7].” The issue however, is that codes have been relatively stagnant.

138

Codes are stagnant in the sense they have not changed or kept with the times in

terms of computers and software programs. So much of the built environment is

constructed with the use of computers, but the code checking process is still limited to

manual methods. The grievances within literature that many practicing engineers have

discussed with regards to the complexity of current building codes have also been noted

within literature discussing the implementation of Computable Building Codes

(CBC’s). CBC’s are the codes that are necessary to completely auto check a design,

that would otherwise require a plans reviewer to manually check. The similarities

suggest that if the problems with complexity are addressed, then the implementation of

CBC’s may be more feasible; however, there are several aspects of complexity within

current codes that will prevent this and must be addresses.

6.2. Complexity

Advancements in Computer Aided Design (CAD) have reached the point where

complete buildings can now be designed in 3-D, right down to the nut and bolt level. It

is suggested that the combination of Building Information Modeling (BIM) and

building codes is part of the evolution of continually progressing design tools [8].

However, in order to meet the demands of society, building codes will likely need a

revolution. In order to meet the demands of ACC there needs to be a drastic change to

the fundamentals of how codes are used and who is using them. This revolution is

likely necessary to move away from traditional methods of code checking and towards

more modern computer based ACC programs. It may be possible for current codes to

evolve to meet the demands of ACC, but the complexity with current codes is making

139

the shift difficult. Instead of attempting to solve the complexity that has plagued the

industry for years, removal may be easier. As such, abandoning current codes for new

modern codes may be the best solution.

6.2.1. Complexity of Provisions

Many code provisions are subjective, which can make encoding them difficult

[9]. These are often the same provisions that make codes complex, not only for

designers but for plan reviewers. The idea that codes need to be more explicit to

transition to CBC’s may have some opposition, because it is suggested that codes need

a blend of explicit and implicit provisions for balance. Too many explicit provisions

hamper design, while too many implicit provisions hamper enforcement [10]. Implicit

provisions are those that likely contain the most subjectivity. To make ACC possible

there needs to be a way to remove the subjectivity. This may mean restricting the

design freedom of what the ACC can handle, but not necessarily for every design.

The subjectivity of provisions is usually addressed through commentary or

annex material that can explain the intent of the provision. This supplementary

information can be extensive, for example the Means of Egress Chapter of the

International Building Code (IBC) is about 30 pages and the commentary is over 100

pages. Both designers and plan checkers utilize this material, but it can often also be

ambiguous. This has worked, for the most part, for manual techniques of code

checking over the past 50 years. However, by removing the need for commentary and

annex material CBC’s can side step the subjectivity issues.

140

6.2.2. Complexity of Codes

The task of overhauling building codes to a form that can be used in an ACC

software program is not simple. However, the United States Tax Code, which is even

more complex than building codes, has been implemented into software that

accountants use to prepare tax returns. This suggests, that regardless of the complexity

level of any given code, implementation into a software program is possible, but this

may not be a true assessment. Although tax software programs exist, they are not all

the same and are often limited in what they can do. However, they are often limited in

what they can do in terms of complexity, and not necessarily completeness. For

example, a program such as TurboTax ® may only do a simple tax return, but can

likely do the entire return. Currently most ACC programs are limited to certain

provisions and cannot do they entire code. Reducing the vast breadth of most building

code could reduce what building designs can be checked, but will ultimately speed up

the process for the simple structures. This is essentially what some tax software does, it

makes simple tax returns easier and does not even attempt more difficult returns.

The majority of literature discusses how developed ACC techniques work on

specific issues, and indicates that many developed techniques are attempting to use

portions of a code, because completeness is not possible for a variety of reasons [11].

For example, disabled access issues, US Court designs, and building envelope designs

are discussed ([12], [13], [14]). Although most articles appear to be attempting the

same challenges, each seems to use a different specific area of concern. Regardless, the

challenges appear to be uniform and the results only partial with respective to complete

141

design ACC. If an ACC software program was limited to certain simple structures then

it may be possible to completely auto check a design.

The idea of separating a building code into two codes: simple and not simple

structures has been discussed within literature, “if we can define simple structures with

sufficient precision for administration by the building official, it should be a fairly easy

job to write a simple code for such structures, and another code for all the remaining

complex structures [15].” Additionally, the idea that most buildings do not need

complicated codes to be constructed safely has been suggested [16]. Separating or

creating a code is not a simple task, but could make the creation of an ACC program

more feasible. The advantages of creating of a code for simple structures in the form of

a CBC, which may be necessary to completely auto check a design, are likely not fully

understood or realized within the engineering community. Software programs like

TurboTax ® have essentially capitalized on the solving a portion of the Tax Code and

creating a tool for simple tax returns to be prepared.

6.2.3. Complexity of the Network

Building codes like the International Building Code (IBC) are complex in

themselves. Additionally, they reference many other documents and create a network

of codes that plan reviewers must navigate to confirm the compliance of a design. This

network of codes is complicated for a variety of reasons, but the most central is that

they are not produced by one single entity. Meaning that any program would need to

include codes from multiple locations, and this would be unlike tax software that deals

142

with only a single code. Granted, the tax code is large and likely the size of the IBC

and all references combined, it is still one code, produced by one entity.

The challenge of overcoming a network of codes rather than a single code will

not be simple. However, simple structures likely do not require the inclusion of many

referenced codes and those that are referenced are likely only partially needed.

Partially in the fact that not all of the code or standard would apply. Although not

simple, including what is necessary from the referenced documents into a single

document avoids network complexity, and would reduce the scope of the references.

6.3. Suggested Approaches

It is plausible that a new code and ACC program can be developed in parallel,

which essentially leaves what is and is not included up to the program developer.

However, if a code is developed for the general purpose of simplification and

implementation of a future online ACC program, then the following are the suggested

steps:

1. Simplify the code language

2. Simplify the code

3. Combine necessary referenced documents

Although it may seem that the first step should be determining what a simple

building is, the simplified code will likely dictate that. However, there are certain types

of buildings that can likely be put into the complex structures category from the start:

high-rises, malls, and arenas for example. Therefore, starting with step 1 and creating

simplified code language and then surveying what buildings fit within the scope,

143

appears to be logical progression. Simplifying the code language will reduce

ambiguities, and certainly restrict the design freedom. However, by expanding the use

of other aspects of the code, it may be possible afford some freedoms. In the process of

simplifying the code language, a majority of the code will also be simplified. For

example, it may be determined that the language for hazardous occupancies and

institutional occupancies are too implicit and are removed. This will not only reduce

the scope of the simplified code but also the codes that need to be included, because

they were previously references.

The importance of code references has been discussed in literature, specifically

with regards to improving technology [17]. However, the inclusion of the necessary

references within the simplified codes does not preclude the use of the information

continually being updated within previous references. If changes occur within a

document that was previously a reference then it may warrant a change to the

simplified code, but it may not be warranted. If the new simplified code is open-source

and connected to a library of designs that have been approved, then testing any

proposed changes may be possible. Open standard protocol or open-source has been

discussed within literature, specifically with regards to ACC [18]. However, the

discussions have been basically limited to suggestions that might work.

The ability to test proposed changes would be further improved once a ACC

program is developed. New information and updates could be implemented in a quasi-

beta type tests. Testing any possible changes against the library of designs could

identify which changes will actual make a difference in safety or health and are

warranted from those that are unnecessary. This is in stark contrast to the current

144

process, where changes can be made to codes without a complete understanding of the

impacts.

The capabilities of Artificial Intelligence (AI) are not fully understood within

the built environment, but the potential exists for an ACC program to learn based on

known designs and on the information gathered as the result of any and all failures.

Clearly this would be a shift even further away from traditional codes, because it could

obviate the need for codes altogether, but is interesting to note. Regardless if AI is

initially used or not, creating an open-source code and coupling it with a library of

approved designs opens up the possibility to fully appreciate catastrophic events,

natural or man-made, with respect to code advancements in real-time. The time it takes

to review old plans, if they are even available, and act on the issue discovered as the

result of a catastrophic event is typically on the scale of months. The ability to

implement a change in the open-source code and identify buildings with potential

failure points, recognized literally seconds prior, will likely be on the scale of hours if

not less.

There have been some reservations about computer use in the design process

discussed in literature, “…leaders in the development and application of computer

aided engineering expressed alarm over the incidence of its misuse. They gave

numerous examples and some of them predicted that a catastrophic failure attributable

computer misuse is only a matter of time [19].” However, not using technology to

create safer buildings and save time in the permitting process would be similar to using

a rotary phone because it is less complex than a cell phone [20]. Designers who chose

the traditional methods or those that are working on complex designs will still use the

145

traditional processes for design review. However, the process should be improved with

the removal of simple projects being reviewed by the online tool.

6.4. Conclusion

Creating a new building code is not a simple task, but having the ability to fast

track permitting will be inviting for many involved in the construction industry. Based

on literature it does not appear that any of the ACC programs described would simply

work with a new code. However, the prospect of developing and ACC program, a tool

that could revolutionize the industry, will certainly pique the interest of many capable

parties. Shifting the attention from traditional building codes to Computable Building

Codes should be at the forefront of the industry focus, but this is not a simple task,

because it will require extensive efforts.

References

1. Field, Charles G., and Steven R. Rivkin. The building code burden. Lexington Books, 1975.

2. Peer, S. "Streamlining the Building Permit Process." Journal of Management in Engineering 2.4 (1986): 265-271.

3. Donohue, Sean. Email to the Author, 2014.

4. Pearson, Cynthia, and Norbert Delatte. "Ronan point apartment tower collapse and its effect on building codes." Journal of Performance of Constructed Facilities 19.2 (2005): 172-177.


6. Kunreuther, Howard. "Mitigating disaster losses through insurance." Journal of risk and Uncertainty 12.2 (1996): 171-187.

146

7. Arlani, A. G., and A. S. Rakhra. "Building code assessment framework." Construction Management and Economics 6.2 (1988): 117-131.

8. Nawari, Nawari O. "Automating codes conformance." Journal of architectural engineering 18.4 (2012): 315-323.

9. Nawari, Nawari O., and Adel Alsaffar. "Understanding Computable Building Codes." Civil Engineering and Architecture 3.6 (2015): 163-171.


11. Yang, Q. Z., and Xingjian Xu. "Design knowledge modeling and software implementation for building code compliance checking." Building and Environment 39.6 (2004): 689-698.

12. Han, Charles S., John C. Kunz, and Kincho H. Law. "A Hybrid Prescriptive/Performance Based Approach to Automated Building Code Checking." International Computing Congress. 1998.

13. Lee, Jae Min. Automated checking of building requirements on circulation over a range of design phases. Georgia Institute of Technology, 2010.

14. Tan, Xiangyang, Amin Hammad, and Paul Fazio. "Automated code compliance checking for building envelope design." Journal of Computing in Civil Engineering 24.2 (2010): 203-211.


16. Pence, E., “Code Complexity and Information Overload”, Structure Magazine, (Oct. 2006): 7

17. Thompson, George N. "The problem of building code improvement." Law & Contemp. Probs. 12 (1947): 95.

18. Dimyadi, Johannes, and Robert Amor. "Automated Building Code Compliance Checking–Where is it at." Proceedings of CIB WBC (2013): 172-185.

19. McGuire, W. "Computers and steel design." Modern Steel Construction 32.7 (1992): 39-2

20. Poston, Randall W., and Charles W. Dolan. "Reorganizing ACI 318." Concrete international 30.7 (2008): 43-47.

147

CHAPTER 7: SUMMARY AND OUTLOOK

7.1. Metric

The developed metric provides a tool for quantifying navigational complexity

within building codes. The tool has been demonstrated on several commonly used

building codes and the results of using the tool show that codes have increased in

navigational complexity over recent years. Navigational complexity within building

codes is subjective and likely based on several facets, and although this research does

not completely confirm what many engineers already believe, that building codes have

increased in complexity, it is one form of evidence. The metric can be used globally

and locally, which provides the ability to examine individual sections of building codes

and identify areas of increasing complexity, as well as comparing new editions of codes

to old editions.

7.2. Numerical and Graphical Representations

Expanding the use of the developed metric to include graphical representations

of navigational complexity provides a tool for visualization, and opens up the

possibility of mitigation. Through graphs it is possible to compare the intended

hierarchical structure of a code to the actual structure. This comparison enables

developers to identify areas of increased navigational complexity, and serve as the

justification for reducing navigational complexity. The graphical representations can

also be shown globally and locally and can be used to identify codes or provisions of

importance. Special attention to important codes and provisions must be given because

any alteration within an important code or provision can have drastic effects.

148

7.3. The Cognitive Limit

It is assumed that navigating cross references within a building code can be

correlated to viewing maps and to moving around a city. Therefore, the cognitive limit

of navigational complexity within building codes was assumed to be the same, two

intermediary points or three successive cross references. The examination of several

commonly used building codes confirmed that instances of three successive cross

references exist and are prevalent. It has also been demonstrated how any successive

reference can quickly create navigational complexity within a code. Although the

results and assumptions that a cognitive limit of successive cross references within a

building code are based on a single concept of cognitive theory, the idea that

navigational complexity has a limit is real.

Unlike using a code to solve a specific design repeatedly, which obviates the

need to learn or use other portions of a code, overall building design is rarely that

limited. The view of an engineer, with regards to navigational complexity and the

cognitive limit of navigational complexity, is highly subjective and is likely based on

their design responsibilities. Those engineers involved with several aspects of building

design are likely more susceptible to navigational complexity and a cognitive limit,

because they need to at least coordinate between multiple chapters of a code, if not

coordinate between the different disciplines involved. The different aspects of design

are often connected by nuances within the codes that result from cross referencing.

Although the cognitive limit of navigational complexity may not be the same as was

assumed within this research, the idea that it exists should not be cast aside.

149

7.4. Future Work

The metric and concepts developed in this research can be used for future work

and testing the effects of navigational complexity is a logical next phase for this

research. However, developing a study to test navigational complexity and its effects

on practicing engineers is not a simple task, because navigational complexity is not a

one step process. Navigational complexity has been shown to exist within various

building codes, but unlike testing an engineer’s ability to solve particular problems,

which has been done previously with the Trial Design Problems [1], testing the effects

navigational complexity entails the use of more than one provision. To test the effects

of navigational complexity the development of design problems slightly more

sophisticated than those used in previous research is necessary, because they need to

incorporate navigational complexity. Navigational complexity manifests over the

course of a design and testing the effects cannot be done through provisions requiring

calculations alone. Design scenarios require, at a minimum, architects or engineers to

work through a design using a portion of a code. This can be done by using the

International Building Code and specifically the Means of Egress Chapter as a starting

point. The Means of Egress chapter provides sufficient code language to ensure

navigational complexity exists, and is also broad enough to allow for the development

of sophisticated design scenarios.

150

To test the effects of navigational complexity the design scenarios must contain

varying levels of interconnectedness, but careful attention should be given to any

scenario. Navigational complexity exists within the context of a code and not

necessarily in an isolated subset. If given a specific code provision and asked to

determine the compliance of a design, navigational complexity is essentially irrelevant.

Using a specific provision and not needing the next sequential provision basically

makes any cross reference within the specific provision more like the Intended

Hierarchical Structure than a cross reference. To avoid over-simplification the design

scenarios must not be too specific and not direct the subject to a specific provision. By

asking slightly vague questions, over-simplification can be avoided, but the questions

will need to be coupled with a design or plan that requires reviewing. For example, a

test subject will be given a design scenario with a bleacher layout and asked the simple

question, “is this design compliant?” Since the test subject would be required to look

through multiple areas of the code to check compliance, i.e. aisle width, aisle length,

handrail spacing, etc., they will encounter navigational complexity. Ensuring

navigational complexity exists within the design scenarios is achievable; however,

capturing the effects of navigational complexity will involve asking the test subjects

how they arrived at their answers.

Examining the results of the how the test subjects arrived at their answers is one

way to test whether navigational complexity is effecting their ability to arrive at the

correct solution. If the test subjects are only asked whether the design is compliant or

not, they have a 50/50 chance of getting the answer correct, even if they did not solve

the problem correctly. However, asking the test subjects how they arrived at their

151

answers will probe further into the basis of their use of the code. Subsequently,

successive cross referencing has been shown to exist within building codes. The

cognitive limit is postulated to be two successive cross references or a starting

provision linked to two successive cross references before navigating back the start

provision or the next sequential provision. The development of design scenarios

consisting of various successive cross references may also provide evidence a specific

number of successive cross references is beyond the cognitive limit.

There are advantages to testing with the use of design scenarios. The first

advantage is that inexperienced engineers and experienced engineers can be provided

with the same problems, which can be used to differentiate experience biases. This

may also prove insightful because many experienced engineers might have already

worked through the design scenario on past projects. This could possibly demonstrate

that navigational complexity still effects experienced engineers. Although time is

always a factor in the real world, consideration to the time spent or allowed on the

problems is not necessary. In most instances engineers are tasked with reviewing an

issue or looking through a code during a design and have ample time to accomplish the

task. In general, they will read the code and proceed to the design. Thus, they are not

under pressure to read and provide an answer immediately, and therefore, the second

advantage is that the tests do not have to be constrained by time. A third advantage is

that many of the references within the Means of Egress Chapter are single document

interconnectedness and testing would only require the use of the IBC. Although this

would be a simplified test, it will provide real-world problems and real-world results,

while manageably constraining the tests.

152

There are a few issues that would need to be addressed with this type of testing.

The first would be that the IBC is generally used by architects and engineers designing

buildings, and therefore testing engineers not involved with this aspect of design is not

necessary. Although testing engineers on unfamiliar codes would likely produce

unbiased results, doing so will not necessarily provide useful insight, because most

users of a code have some familiarity. Testing engineers on codes they use or will

likely use in their fields of practice is a more effective method of addressing existing

issues. Therefore, one disadvantage to this type of testing is that it would be limited to

a specific group of engineers, which would also likely limit the pool of engineers in a

given area. The second issue that needs to be addressed is the method of presenting the

test. It will be difficult to get architects and engineers in one room to conduct a test.

Therefore, the best method will probably be through email, which can make

dissemination difficult and is also a disadvantage.

This type of study will certainly have the same intentions as the Trial Design

Problems [1]:

1. Investigate how practicing engineers interpret and apply current code

provisions.

2. Investigate the consistency of engineering judgment of practicing

engineers.

3. Promote dialog and continuing education among practicing engineers.

4. Identify and promote needed improvements in the code requirements.

The intentions are the same because the goal of studying navigational

complexity is to make codes better, which is the same goal for most people involved in

153

the development process of any code. A study of navigational complexity, as

described, will likely need to involve a group of people, and while testing the effects

navigational complexity may be the primary goal, there are certainly other aspects of

codes that could be part of the study. This type of study will also need to be conducted

over an extended period of time, because code cycles and changes are necessary to

investigate increasing complexity or new issues.

7.4.1. Code Development Process

Although it may be necessary to provide further proof that building codes are

navigationally complex, this research has presented the results from three of the more

universally used codes. Providing further evidence is not likely necessary, and as such,

the next step would be to implement the metric and graphical representations into the

code development process. This would not be a simple task but could likely be

undertaken as part of a larger project. The three-year code cycles would provide

sufficient time to completely analyze a code, but the standard process would also

necessitate condensed work during the time when proposed changes are being

submitted.

The results and specifically graphical representations of any code would likely

be a welcome addition to the process, but will require support from the code developer.

There are times when code committees meet, but attendance is not always required to

propose a change. Therefore, the dissemination of any graphical representations and

ideas would certainly need to facilitated by the developer to reach all parties involved

in the process.

154

7.4.2. Future Codes

The ability to take a 3D design of a building and enter it into a program that can

check it against the building code has been discussed for years. The ability to do so

will likely revolutionize the industry. There has been extensive research on how

software programs can take the building codes and check a design, but these programs

are often limited to specific portions of the code because of the code’s complexity.

Essentially, codes will need to change if the complexity becomes too great for the

current methods of plans review, or if users demand better code checking software.

The question is, what will happen first?

Unlike some technologies that come and go, building codes are likely here to

stay, but the way they are used is almost certainly going to change. As demonstrated

the complexity within building codes is increasing, and reducing complexity in them

appears to be necessary if the industry stays with the current methods. However, based

on the extensive research into computer checking designs, it appears the shift away

from traditional methods is on the horizon. The concept of blockchain or some other

new technology may provide additional support for the transition. Blockchain is

already being considered as a way to electronically handle construction contracts, and it

is likely that other new concepts will be generated as a result. The ability to capture

building drawings in the cloud is not new, but retrieval is still complicated. The ability

to access old building plans is important after issues with previous building codes are

discovered, but the ability to access drawings can be difficult once properties are

bought/sold.

155

There are similarities in the complexity issues of current codes and with the

codes necessary to computer check a design, but not all issues will be the same. Future

work will be necessary to determine the differences and identify where complexity

exist within the new codes. Computers have the ability to handle vast amounts of data,

which means the complexity of the news codes can unquestionably be higher, but

inevitably the engineers who implement the new codes must understand the limitations.

References

1. Wilcox, C., B. Nuttall, and T. Barnett. "Connection Details—Practicing Engineers and the Code." 2011 Structures Congress. 2011.

156

Bibliography

ACI Committee 318. "Building Code Requirements for Structural Concrete (ACI 318-14): An ACI Standard: Commentary on Building Code Requirements for Structural Concrete (ACI 318R-14), an ACI Report." American Concrete Institute, 2015.

ACI Committee 318. "Building Code Requirements for Structural Concrete (ACI 318-14): ACI 318-11 to ACI 318-14 and ACI 318.2-14, Transition Key." American Concrete Institute, 2015.

Arlani, A. G., and A. S. Rakhra. "Building code assessment framework." Construction Management and Economics 6.2 (1988): 117-131.

Benzarti, Youssef. "How taxing is tax filing? Leaving money on the table because of hassle costs." Browser Download This Paper (2015).

Building Code Requirements for Structural Concrete: (aci 318-71). Farmington Hills, Mich: American Concrete Institute, 1971.

Building Code Requirements for Structural Concrete: (aci 318-95) ; and Commentary (aci 318r-95). Farmington Hills, Mich: American Concrete Institute, 1999.



Bulleit, William M. "Structural building codes and communication systems." Practice Periodical on Structural Design and Construction 17.4 (2012): 147-151.

Cowan, Nelson. "The magical mystery four: How is working memory capacity limited, and why?." Current directions in psychological science 19.1 (2010): 51-57.

Cross, Hardy. Engineers and ivory towers. McGraw-Hill, 1952.

DeFriez, C., “How Code Complexity Harms Our Profession”, Structure Magazine, (July, 2014): 50.

DeFriez, C., “How Code Complexity Harms Our Profession, Part 2”, Structure Magazine, (Sept., 2014): 74.

Deschamps, Denise, Building Code Development and Enforcement: Impact on Accessibility for Persons with Disabilities, 2010.

157

Dimyadi, Johannes, and Robert Amor. "Automated Building Code Compliance Checking–Where is it at." Proceedings of CIB WBC (2013): 172-185.

Donohue, Sean. Email to the Author, 2014.

Field, Charles G., and Steven R. Rivkin. The building code burden. Lexington Books, 1975.

Gallotti, Riccardo, Mason A. Porter, and Marc Barthelemy. "Lost in transportation: Information measures and cognitive limits in multilayer navigation." Science advances 2.2 (2016): e1500445.

Galvan, Sara C. "Rehabilitating rehab through state building codes." The Yale Law Journal (2006): 1744-1781.

Ghosh, Satyendra K. "Significant changes from the 2011 to the 2014 edition of ACI 318." PCI Journal 61.2 (2016

Han, Charles S., John C. Kunz, and Kincho H. Law. "A Hybrid Prescriptive/Performance Based Approach to Automated Building Code Checking." International Computing Congress. 1998.

International Code Council, et al. International building code. International Code Council, 2003.

International Code Council, et al. International building code. International Code Council, 2015.

King, Leonard William. The code of Hammurabi. Netlancers Inc, 2014.

Krause, Kate. "Tax complexity: Problem or Opportunity?." Public Finance Review 28.5 (2000): 395-414.

Kunreuther, Howard. "Mitigating disaster losses through insurance." Journal of risk and Uncertainty 12.2 (1996): 171-187.

Laffer, Arthur B., Wayne H. Winegarden, and John Childs. "The economic burden caused by tax code complexity." Austin: The Laffer Center, Texas Public Policy Foundation. Available online: http://www. laffercenter. com/2011/04/the-economic-burden-caused-by-tax-code-complexity (2011).

Lee, Jae Min. Automated checking of building requirements on circulation over a range of design phases. Georgia Institute of Technology, 2010.

MacGregor, J. G. "A Simple Code-Dream or Possibility?." Special Publication72 (1981): 199-218.

158

Martín, Carlos. "Response to" Building Codes and Housing" by David Listokin and David B. Hattis." Cityscape (2005): 253-259..

Mathews, D. D. "Towards a European Code for Concrete–Can Concise Codes be Comprehensible and Comprehensive?." The Structural Engineer 54.12 (1976): 476-477.

McConnaughey, John S. An economic analysis of building code impacts: a suggested approach. Washington, DC: US Department of Commerce, National Bureau of Standards, 1978.

McGuire, W. "Computers and steel design." Modern Steel Construction 32.7 (1992): 39-2

Mitchell, Melanie. Complexity: A guided tour. Oxford University Press, 2009.

Morgan, Jessica L. "Have wind design provisions become too complicated? a look at the progression of design provisions for mid-rise buildings." (2009).

National Fire Protection Association. NFPA 101 Life Safety Code. National Fire Protection Association, 2015.

National Fire Protection Association. NFPA 101 Life Safety Code. National Fire Protection Association, 2012.

National Fire Protection Association. NFPA 13: Standard for the Installation of Sprinkler Systems. National Fire Protection Association, 2016.

Nawari, Nawari O. "Automating codes conformance." Journal of architectural engineering 18.4 (2012): 315-323.

Nawari, Nawari O., and Adel Alsaffar. "Understanding Computable Building Codes." Civil Engineering and Architecture 3.6 (2015): 163-171.

Pearson, Cynthia, and Norbert Delatte. "Ronan point apartment tower collapse and its effect on building codes." Journal of Performance of Constructed Facilities 19.2 (2005): 172-177.

Peer, S. "Streamlining the Building Permit Process." Journal of Management in Engineering 2.4 (1986): 265-271.

Pence, E., “Code Complexity and Information Overload”, Structure Magazine, (Oct. 2006): 7.

Petroski, Henry. To engineer is human. New York: St. Martin's Press, 1985.

159

Pierson, D., “Who Hijacked My Building Code?”, Structure Magazine, (April, 2016): 66.

Pierson, D., “Changing Building Codes – Are They Really That Bad?”, Structure Magazine, (May, 2013): 58.

Pitt, P. H. "Towards a simplified code of building control." The Journal of the Royal Society for the Promotion of Health 99.1 (1979): 3-7.

Poston, Randall W., and Charles W. Dolan. "Reorganizing ACI 318." Concrete international 30.7 (2008): 43-47.

Salama, Jerry J., Michael H. Schill, and Martha E. Stark. Reducing the Cost of New Housing Construction in New York City. New York University School of Law, Center for Real Estate and Urban Policy, 1999

Scott, J. G. (1997). Architectural building codes: A graphic reference. New York: Van Nostrand Reinhold.

Searer, Gary R. "Poorly worded, ill‐conceived, and unnecessary code provisions." The Structural Design of Tall and Special Buildings 15.5 (2006): 533-546.

Searer, G., et all. 2007. “Are we really learning from Earthquakes? Declining Quality and Increasing Complexity of Modern Building Codes”. In Proceedings of the 9th Canadian Conference on Earthquake Engineering. Ottawa, Canada, June, 2007.

Shapiro, Stuart. "Degrees of freedom: the interaction of standards of practice and engineering judgment." Science, technology, & human values 22.3 (1997): 286-316.

Siess, Chester P. “The 1971 ACI Building Code Too complicated, too complex or both?” ACI Journal (1974)

Sporns, Olaf. Networks of the Brain. MIT press, 2010.

Stubbs, M. Stephanie "The Widening Web of Codes and Standards." Doors and Hardware (1988).

Tan, Xiangyang, Amin Hammad, and Paul Fazio. "Automated code compliance checking for building envelope design." Journal of Computing in Civil Engineering 24.2 (2010): 203-211.

Thompson, George N. "The problem of building code improvement." Law & Contemp. Probs. 12 (1947): 95.

Title 26 – Internal Revenue Code (2016)

160

Title 26 – Internal Revenue Code (1954)

Uniform Building Code. Whitter, Calif. (5360 South Workman Mill Rd., Whitter 90601: International Conference of Building Officials, 1970



Vaughan, Ellen, and Jim Turner. "The value and impact of building codes." Environmental and Energy Study Institute White Paper (2013).

Wight, James. Email to the Author, October 2, 2013

Wilcox, C., B. Nuttall, and T. Barnett. "Connection Details—Practicing Engineers and the Code." 2011 Structures Congress. 2011.

Yang, Q. Z., and Xingjian Xu. "Design knowledge modeling and software implementation for building code compliance checking." Building and Environment 39.6 (2004): 689-698.

161

APPENDIX A: METRIC DEVELOPMENT

New Engineer/New Code Mid‐Level Senior Engineer

Electronic Time (m) Electronic Time (m) Electronic Time (m)

SDI‐1 1.75 SDI‐1 1.3 SDI‐1 1

SDI‐2 3 SDI‐2 2 SDI‐2 1

MDI‐1 5 MDI‐1 3 MDI‐1 2

MDI‐2 10 MDI‐2 4 MDI‐2 3

MDI‐3 15 MDI‐3 2 MDI‐3 1

New Engineer/New Code Mid‐Level Senior Engineer

Paper Time (m) Paper Time (m) Paper Time (m)

SDI‐1 2 SDI‐1 1.5 SDI‐1 1

SDI‐2 5 SDI‐2 2 SDI‐2 2

MDI‐1 10 MDI‐1 5 MDI‐1 3

MDI‐2 15 MDI‐2 7 MDI‐2 5

MDI‐3 20 MDI‐3 3 MDI‐3 1

Figure A.1: The different types of codes, levels of engineers and the time associated with the classifications of interconnectedness

162

APPENDIX B: SAMPLE GRAPHS - IBC CHAPTER 9

Figure B.2: Complete list of provisions within the IBC Chapter 9

163

Figure B.3: Complete intended hierarchical structure of the IBC Chapter 9 with associated edges

164

Figure B.4: Complete intended hierarchical structure of the IBC sub-section 903

165

Figure B.5: Complete intend hierarchical structure of the IBC sub-section 903 with all references.

166

APPENDIX C: SUPPORTING GRAPHS

Figure C.6: Chapter 5 of the ACI 318 1995 edition. The graph is a representation of the intended hierarchical structure.

167

Figure C.7: Chapter 5 of the ACI 318 1995 edition. The graph is a representation of the intended hierarchical structure as well as the references made within the Chapter to other sections of the

Code and other Codes.

168

Figure C.8: A representation of a code network. Colored dots represent codes.