Engineering Practice and Bridge Design

In April of 1986, ACM’s CACM (Communications of the ACM) published an article entitled “A Computer Science Perspective on Bridge Design” which was an interview of Gerald Fox (a bridge engineer) by Alfred Spector and David Gifford: http://portal.acm.org/citation.cfm?id=5684.6327&coll=ACM&dl=ACM&idx=J79&part=magazine&WantType=Magazines&title=Communications%20of%20the%20ACM&CFID=47665715&CFTOKEN=13076261

Since it requires a subscription to the ACM Digital Library to get access to this article, I thought I would highlight some points in the article, specifically where it discusses ideas that have some relevance to software design practice. It should be noted that all the material quoted comes from Fox’s statements as Spector and Gifford acted as interviewers only, though they did control the kinds of questions asked. The rest of the commentary is my own take on the material.

The first point made in the article is the significant difference in approach used for small vs large bridges. Small bridge design can get by with “simple calculations or experience.” Large ones usual employ “several alternative designs” during a “preliminary design phase”. These alternatives are usually presented to a client with one recommended over the others. “There would also usually be hearings to get the public’s reaction.” In software, the “public” could be considered end-users.

The next interesting comment made is that long-term cost is not a major concern since “initial cost is the primary thing clients look at today.” This concern for initial cost has an important impact on the materials and design proposed and accepted. However, the costs for all aspects of design usually pale in comparison to actual construction cost. This is similar for most manufactured products. Thus, a good bit of effort over the years has been spent in ways to optimize and improve the costs for construction/manufacturing.

One telling remark made by Fox was that everyone involved with the design phases “have always understood that the quality of the design is more important than its cost,” again, because of the huge cost of construction. It is noted that design cost is usually “less than 6 percent of total cost, and even less for larger bridges.” This represents one major difference between developing software (which is almost completely a design activity) and creating physical products.

The next major point is that, “There’s usually not a lot of very complex analysis involved, unless the project represents a significant departure from experience.” I believe this is an area where software development has continued to struggle for decades. Ensuring that necessary (domain and technical) experience exists and that this body of experience grows in some organized fashion may be one of the great limiting factors software development currently faces. It contributes greatly to the perceived complexity in software projects. In this regard, complexity from lack of knowledge of existing experience may even be considered an “accidental” (to use Fred Brooks’ term) element of software development.

Related to this is discussion about the existence and use of “standard values for the allowable stresses and loadings” which exist in basic bridge design. Engineering also benefits from much knowledge about the characteristics of the materials it works with, which is where a good bit of basic science comes into engineering. In contrast, much software is built starting from atoms/molecules rather than whole materials, though reusable libraries, patterns, O-O design are/have been attempts to raise the level of design. Fox does note, however, that “additional criteria” are usually needed for larger bridges, especially with regard to “natural phenomena” where a good bit of risk analysis is performed “to establish acceptable bounds.”

There is, of course, considerable modeling done for larger bridges, both mathematical and physical, both to determine “where joints, pins, and other connections are to be placed” and to consider dead and live loads. In software, we can think of these as interface and performance design. A key in both bridge and software design, though, is determining “how many situations to account for.” In particular, both must be concerned for combinations of conditions. Using one of Brooks’ terms again, we have an “essential” aspect of complexity in this regard, both for bridges and software.

One factor crucial in engineering design for physical products is the effect of component wear. For example, in bridge design, there is “fatigue” brought about by the stresses the bridge undergoes both through use and the impacts of natural phenomena. Again, combinations of both are important to consider. Concern for fatigue and component failure drives assessment of safety limits as well as maintenance considerations. The former are a design concern while the latter is usually not factored into costs, though the needs of such maintenance are well understood. In this regard, software has little concern as it does not “wear out” and repair maintenance of software is due to flaws in the original design, not flaws which develop “naturally” through use. Indeed, Fox points out how “inadequate inspections” of existing structures, are more likely to be the cause of failure than design/construction flaws. However, many examples of catastrophic failure are design/construction flaws, e.g., Tacoma Narrows Bridge and Kansas City Hyatt Regency walkways.

The interviewers next ask about the numbers of people involved in design and the use of pre-made components. Fox notes that too many people involved in design can “get in each other’s way, and it becomes more difficult to keep everyone up-to-date with changes”. But design can be divided up between groups with “one engineer in charge who would ensure all the groups were designing compatible structures.” Regarding standard components, Fox states the there is “very little…except for small-span bridges. Most elements are built up out of steel plates.” Fox does say that there are some standard sizes for “angles and I beams,” but, overall, “standardization is not very great in terms of components” for large bridges. Fox continues by saying that “economies of scale with a large bridge may make it more logical to use nonstandard components.” (Again, however, “components” are not atoms and molecules.)

Quite telling is Fox’s statement that, “It’s difficult to get every nuance of the design into the drawings” to be used for guiding construction and that contractors “may add extra material to the structure to reduce the stresses.” Fox points out the “tendency for the consulting engineering firm not to be involved in the construction process.” He later states that he feels this is something that needs to change. In software, we might compare this to separation between groups doing architectural and high-level design and those involved in actual low-level design and coding. In both engineering for physical products and software “on site” decisions are frequently made to get things to “fit” properly.

Continuing with this theme of change and design modification, Fox states that, even with computer design optimization, bridge design relies largely “on experience and trial and error” during the design phase. Fox does say computers allow engineers to “be more precise” about safety factors. Henry Petroski, who has written extensively on engineering practice and design, expressed concern that use of computer programs for safety optimizations posed some danger as they tended toward less rechecking of calculations, etc. as would have been done before their use. Indeed, he talks about how safety concerns ebb and flow relative to cost considerations. Cutting safety close (being more “precise”) combined with on-site modifications sometimes leads to failures which promote a new phase of over-engineering for safety until, after a while, cost concerns begin to drive the tolerances closer, until the next failure.

Fox says, regarding failure, that this usually occurs when “we extrapolate beyond out experience and models.” And as Petroski and Fox both note, it being a general principle of engineering, failure drives much of the learning, though not necessarily catastrophically so. Fox does not that, in general, bridge design is “conservative with our loading” since natural phenomena and ultimate use cannot be predicated exactly, e.g., wind and traffic. Fox says believe that, though “understanding of materials is also quite good,” a safety-factor of “1.8” is commonly used to account for “variability in loads or materials, as well as possible mistakes in the model.”

When it comes to design “correctness,” Fox points out that “good engineers check everything” and that this is “always done by an engineer who did not work on the original design.” When all design documentation is complete, another review occurs “by a senior engineer for completeness.” One of the tradeoffs made that is checked has to do with redundancy versus safety factors in the individual components. Redundancy can keep a structure from failing even if some element of it fails. But such redundancy is not used in certain bridge types because of the cost. This is where extra safety factors are used to “compensate for lack of redundancy.” Small bridges are going to be more redundant, due to cost, than larger ones. (It is interesting that Fox says how there are “perhaps 100 failures of old small bridges in any given year” though fatalities in such cases are rare.)

At the end of the article, there is a section entitled “Editors Conclusions” which list the following as “specific differences in the disciplines”:

1) Bridge design “is much more structured than computer systems design.”

2) Standardized, conservative specifications exist for many aspects of bridge design and components.

3) In terms of person-years, bridge designs are not as complex as software systems.

4) There is greater attention to reliability in bridge design and considerable checking of design specifications.

5) Analytical models are used more in bridge design and are more advanced.

6) Bridge design produces specifications that are “explicit” and “comprehensible” by many outside of the design group(s).

7) Design and construction of bridges is separated far more than in software where they can be no separation at all.

Now this is an old article, but many of the themes sound quite familiar, even today. Over the last 10 years or so, I have found it very informative and interesting to read about various forms of engineering practice and design. As noted above, books by Henry Petroski are often noted by others and a book entitled Discussion of the Method by Billy Vaughn Koen provides a combination of practical and philosophical examination of engineering problem-solving.