Based on the number of times I've seen the comparison come up in my career, you might think that bridge building and software development were related in some way:
Programming is a language, with only one case: imperative ;).
I think that the difference between e.g., mechanical engineering and software engineering are perceived the way they are BECAUSE of the immaturity of software. Mechanical engineering was able to move past a certain point because rather than having to hammer out their own, engineers discovered the One True Nail, or the One True Lockwasher, or what have you. The same is not true of software, at least not yet.
God DID invent the x86, through the merit of the fact that he composed the physical laws that allow it to be created. The trick is that with software we’re working at the meta-meta level, and that’s what causes the uncertainty inherent in software. Mechanical engineering is making chopsticks. Writing software is making chopsticks WITH chopsticks.
“If you like computer programming, then you’ll love math.”
Since my background has even less to do with math/engineering – let’s just say I studied languages – I would occasionally hear the even more specious comparison “Well, programming is a kind of language, too, isn’t it? That’s why you like it.” Uh … no.
I think that the comparison with math is true at a relatively uninteresting level, namely that math and programming require the ability to think logically and to put together chains of reasoning. Programming also requires a certain kind of internal consistency. I suppose that’s why many people assume that someone good at math would be good at programming. As I say, it’s not a sophisticated comparison, and in any event tells us very little about programming as a formal discipline like engineering.
I think most of the engineering comparisons are really not even point-by-point comparisons between, say, civil engineering and computer science as they are expressions of frustration that a field like programming seems so resistant to being corraled into the type of predictive patterns that enginnering has. (Not that traditional engineering doesn’t fail specatucularly now and again, witness Charles de Gualle airport in Paris, as but one recent example.) People whose job it is to worry about managing complex programming projects yearn for the type of planning confidence that engineering has (or has to a greater extent, anyway). Just a thought, anyway.
programming seems so resistant to being corraled into the type of predictive patterns that enginnering has.
Well, imagine what civil engineering would be like if the laws of physics changed every 10 years. I think you’d see the same kind of frustration. Software has no bedrock foundation; we’re literally making everything up as we go along.
That’s why I think the Math comparison is a better one, but I agree-- it’s still pretty poor. As a software developer, I think reaching out to other disciplines as examples of “maturity” is risky at best and counterproductive at worst. We should focus on learning from ourselves within our own discipline.
You may like this quote on River Engineers:
a href="http://exold.com/quote/river-engineers"http://exold.com/quote/river-engineers/a
It’s not engineering, it’s not science.
Is it math?
Definitely not!
Then what is the process of writing software? A word processing excercise that culminates in a super-syntax checker called a compiler?
I’m not disagreeing with you, but the list of things that software development isn’t like isn’t very interesting. Is it like bowling? no. Being drunk? no. Skydiving? no. Roller skating? How about no!
My own thoughts are that as long as humans are involved in typing in low-level code, we will continue to live in the monkey house. Once a reasonable level of abstraction can be determined that makes coding as word processing obsolete, I think we’ll have a much more productive discussion on this subject.
Henry Petroski also has a number of books that touch on this theme:
http://composite.about.com/cs/bookspetroski/
To Engineer Is Human : The Role of Failure in Successful Design
http://www.amazon.com/exec/obidos/tg/detail/-/0679734163
This covers the famous Tacoma Narrows bridge failure incident, among other things.
Engineers of Dreams : Great Bridge Builders and the Spanning of America
I think there is an overlooked point when comparing software with other engineering projects. Many “real” engineering projects are simply copies of other existing projects. The difference between two interstate overpasses is minor, they are just copies of the same design. For software making a copy is a trivial task. So trivial that it is simply overlooked when making comparisons. That is why we are constantly working on new projects (or features). If the level of effort to install a finished piece of software on a new computer was comparable to building a copy of an existing overpass in a new location things would move more slowly and more stable. The fact that we can innovate and distribute new software at an amazingly fast rate both a benefit and a detriment to our industry.
There also seems to be this misconception that traditional engineering projects are always finished on time and on budget. Try to find a truly unique building project that was finished as designed, on time, and within its budget. Software companies are turning out new, unique products every day. If you throw out the engineering “copies” I think the software industry is doing better than we give ourselves credit for.
I did a quick search for “bridge cost overrun” and found 129,000 hits. Including these two interesting papers:
What Causes Cost Overrun in Transport Infrastructure Projects?
"Nine of 10 transport infrastructure projects fall victim to cost escalation"
http://flyvbjerg.plan.aau.dk/COSTCAUSESASPUBLISHED.pdf
Megaprojects and Risk
"Many projects have strikingly poor performance records in terms of economy environment and public support."
http://assets.cambridge.org/052180/4205/sample/0521804205WS.pdf
Interesting read, this!
And while reading the comments on what software devellopment could be like a thought springs to mind: it is somewhat like surgery, it may look like something that’s been done before at first glance, but when you dive deeper into it, it’s like something you’ve never seen before.
I know this doesn’t fully add up for surgery, but as every person is unique, the basis from which a surgeon works has great simmilarity to what software developers have to start out with.
so much for my 5 cents.
Punky
Actually, the “surgery” metaphor was used in the “The Mythical Man-Month: Essays on Software Engineering” a book on software project management written by Fred Brooks 30 years ago.
Joannes
This bridge has nothing to do with software development and that’s just plain common sense.
http://www.vanderburg.org/Blog/Software/Development/building_bridges.rdoc
A parallel that I like is the “creative” one.
Designing software is like creating a bridge design that nobody has ever thougt of before.
Or, Designing software is like creating a movie with novel effects and narrative and techniques.
Or, Designing software is like (umm, maybe) raising an unruly child and trying to get them to stop spewing their breakfast on your lap … 
"…There also seems to be this misconception that traditional engineering projects are always finished on time and on budget. Try to find a truly unique building project that was finished as designed, on time, and within its budget… “”
The Pentagon.
Thanks for this excellent article!
Engineering and software development are the same in at least one regard: No matter what process you follow to create new things, you should measure your progress against some standard, evaluate how well you are doing and follow strategies to improve your record. True, this could apply to most anything, but the specific application to engineering and software development are very similar.
–
http://www.tech4d.com/blog/2007/06/28/software-engineers-are-not-engineers/
Software is all of the above things and none of them.
Perhaps the problem arises when we try to compare software engineering to only one thing—the comparison inevitably falls down (like a badly built bridge).
Software is unique—perhaps we should simply recognize it as such and stop trying to define it in terms of other things (although, like our software models, these analogies can present a limited but useful perspective).
When we fully realise this, we will start making decent in-roads into solving the unique problems of software development.
This picture of this bridge they built is magnificent! It is a truly remarkable picture and bridge! WOW!!!
It is math. Anyone who says otherwise either doesn’t know what math is or doesn’t know how software works, probably both. It is the hardest applied math because it is the purest applied math. Math isn’t arithmetic.
I think it’s a bit strange to make a comparison with bridge building and software development, if you want to make such ambiguous associations, you could connect almost any 2 products or methodologies.
I find it surprising that a bunch of people who apparently have no real concept of what real engineering is are commenting on this. Bridge overpasses are not all essentially copies of what was done before. Yes, you are using a similar structure, but each location presents particular challenges, be they in maintenance of traffic operations, construction sequencing, geotechnical constraints, location issues, etc. Generally speaking, concrete structures are very repetitive utilizing similar beam sections in many structures. Steel structures, on the other hand, are completely different and there is an infinite combination of plate sizes that would yield adequate results. I’m not even going to talk about post-tensioned, cable-stayed, truss, or arch structures.
Not only that, but you are all referring to one specific subset of engineering, namely structures. You are completely ignoring chemical, electrical, industrial, mechanical, aerospace, or geotechnical engineering, not to mention the remaining branches of civil engineering (hydraulics, traffic, transportation, etc). It is capricious to state that engineering is repeating previously conceptualized designs to fit a current situation. While that may be SOMEWHAT accurate in STRUCTURAL engineering, it is completely untrue of say electrical or mechanical engineering. Do you really think that the inventors of the Synergy Energy Drive from Toyota were copycatting? Building on a previously existing design, yes, but not copying some engine that worked somewhere else and putting it into a new frame. And while they may be working in God’s constraints, they are also trying to further understand those constraints (meaning, those constraints are NOT fully known or understood) in such a manner as to increase the machine’s efficiency without a loss of power. That is but one example.
Can a civil engineer say that More than half of everything I know will be obsolete in ten years? HECK YES I can (maybe not completely obsolete, but what they do now will NOT be what is done in 50 years). I’m pretty sure that if John Roebling miraculously came back to life today and wanted to design the Brooklyn Bridge, it wouldn’t happen. Granted, that WAS 100 years ago, not 50. The basic fundamentals of civil engineering, i.e. mechanics of materials, will not and have not changed. However, design methodology has changed, software and calculators have and will continue to be developed, and our beloved codes are constantly being updated and rewritten. Case in point, strut-and-tie method for shear and torsion design in concrete. That didn’t even exist 50 years ago. Not to mention changes in technology (prestressed concrete was first used in 1937, post-tensioned concrete in the US has only been around for 40 years) and changes and advances in materials and material properties (steel has only been used for bridges for around 150 years - prior to that it was cast iron, concrete strengths used to top out around 4000 psi and we can now get over 10000 psi and composite reinforced polymers are being invented and researched as a new structural material). Anyway, point is, things change in civil engineering, too.