The Artima Developer Community
Sponsored Link

Agile Buzz Forum
Bridges and Software

1 reply on 1 page. Most recent reply: Feb 8, 2007 1:37 PM by robert young

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 1 reply on 1 page
Glenn Vanderburg

Posts: 114
Nickname: glv
Registered: Jun, 2003

Glenn Vanderburg is a software craftsman located in Dallas, Texas.
Bridges and Software Posted: Feb 8, 2007 11:15 AM
Reply to this message Reply

This post originated from an RSS feed registered with Agile Buzz by Glenn Vanderburg.
Original Post: Bridges and Software
Feed Title: Glenn Vanderburg's Software Blog
Feed URL: http://www.vanderburg.org/cgi-bin/glv/blosxom/Software?flav=rss
Feed Description: Glenn Vanderburg's blog about software development
Latest Agile Buzz Posts
Latest Agile Buzz Posts by Glenn Vanderburg
Latest Posts From Glenn Vanderburg's Software Blog

Advertisement
(I sent this to the NFJS speakers’ mailing list last week, and Ben Galbraith suggested I repost it here.)

Every now and then I hear someone compare software development to bridge building. (Bridge building, of course, is just a placeholder here for "real engineering," which in the speaker’s mind is much cleaner and more manageable than the current messy state of software development.) Sometimes it’s "software development isn’t like building bridges," while on other occasions it’s "software development should be more like building bridges." In either case, though, the implication is clear: bridge building is predictable, rote, unexciting, very manageable work, and software development is not. The only difference is whether the speaker likes software development the way it is, or wishes it could be different.

I think both positions are misinformed. And no, I’m not about to pull out my magic prescription for how to solve all the software industry’s problems by making it more like bridge building. In my experience, software developers tend to have an idealized, unrealistic view of what "real engineering" is like. Sure, some kinds of bridges are so well understood by now that there’s very little risk involved; freeway overpasses and the like are churned out regularly and routinely (in much the same way that simple CRUD applications, whether web- or desktop-based, are usually safe bets for even inexperienced development teams). But from what I’ve learned, bridge building in general is a lot more like modern software development than most people realize. And I think the software industry can learn some lessons from the history of bridge building.

Take, for example, the bridges of Swiss engineer Robert Maillart. His best known bridge, Salginatobel, was just featured in a really nice piece about some of the best man-made structures.

Maillart was seeking new designs that would take advantage of the properties of a new material: reinforced concrete. It had been in use for some time, and builders had figured out how to work with it, but Maillart realized that reinforced concrete had unique properties that would permit the use of new forms, resulting in significant savings (due to reduced material costs).

The formal methods used by civil engineers at the time weren’t up to the challenge of analyzing these structures (known today as "hollow box arches" and "deck-stiffened arches"). Maillart verified the designs empirically, by building models, rolling barrels full of concrete over them, etc. etc. The civil engineering establishment of the day vilified him as a charlatan who was endangering lives and cheating his customers by building bridges that would fall down. But he got customers anyway, because his designs were much, much cheaper to build. (The fact that they were strikingly beautiful didn’t hurt.)

Another engineer of the time was Leon Moisseiff, a strong proponent of formal methods and the developer of "deflection theory," at the time the state of the art in mathematical analysis of suspension bridges. Moisseiff designed a bridge intended to be a showpiece for the power of deflection theory. It was the Tacoma Narrows bridge. After its famous collapse, other bridges that had been designed with Moisseiff’s assistance (such as the Golden Gate) were retrofitted with stiffening trusses. It turned out that deflection theory was deeply flawed in a way that nobody had yet realized.

One of Maillart’s bridges did fall down … after being buried under an avalanche. One was demolished because more capacity was required. The rest are still in use, and the forms he pioneered are now standard design taught to civil engineers. The math eventually caught up with Maillart’s methods. As the story I linked to above notes, Maillart is an inspiration to the current superstar of bridge design, Santiago Calatrava.

I think there are some important lessons here for the software profession. The lesson is definitely not that "real engineering" is a mechanistic, purely construction-oriented process, which is the lesson that is usually assumed when software is compared to bridges.

Note: I have at best an interested layman’s knowledge of the history of bridge engineering. Sources include Henry Petroski’s wonderful Engineers of Dreams: Great Bridge Builders and the Spanning of America for information about Moisseiff, and David P. Billington’s article "The Revolutionary Bridges of Robert Maillart" (from the July 2000 edition of Scientific American). For what I believe to be the best description of the true relationship between software development and other engineering disciplines, I encourage you to read "What is Software Design?", Jack Reeves’ brilliant essay.

Read: Bridges and Software


robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Bridges and Software Posted: Feb 8, 2007 1:37 PM
Reply to this message Reply
>> The lesson is definitely not that "real engineering" is a mechanistic, purely construction-oriented process, which is the lesson that is usually assumed when software is compared to bridges.

I don't believe that the statement of what is the Lesson is correct, nor that this definition of the Lesson is what is assumed when comparing software to Real Engineering.

For one thing, the number of fallen down bridges as a fraction of bridges is arguably infintesimal compared to the same fraction for "major software systems". That an intuitive civil engineer could make a design that worked, while an analytical civil engineer made one that failed, does not, ceteris parabus, invalidate the analytic approach.

For another, the comparison is usually, "if they built bridges the way they build software, they'd all fall down in a week". This story is not a contradiction to that expression. The expression is that software is ad hoc and undisciplined, real engineering is studied and disciplined.

Only if bridge builders gave up their slide rules and FEA software and used napkin notes instead; and had fewer collpases, would there be a contradiction to the common expression.

Flat View: This topic has 1 reply on 1 page
Topic: RailsEdge Rocks Previous Topic   Next Topic Topic: What the Beatles Deal means

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use