*
programming and human factors
by Jeff Atwood
*
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:
[..] my Dad, who is a “real” engineer, is out visiting for a few days. We got talking tonight about the essence of real engineering and attempted to understand if software development is approaching the level of say mechanical or chemical engineering in terms of maturity of the field. (Brad Abrams)
[..] building software is an immature engineering discipline, which most notably shows in our lack of ability to make true black boxes. "Classical" engineering, like building bridges, dams, and other structures, has mastered the art of specifying components to such a degree that they can be described with only a few parameters. In the art of software engineering, we do not have this down yet. (Kees Leune)
"Our standards have inappropriately been lowered by our daily experience," said Ken Jacobs, Oracle's vice president of product strategy. "We have to bring software engineering the kind of maturity we have in building bridges and buildings. We don't expect buildings to fall down every day."
I find these discussions extremely frustrating, because I don't think bridge building has anything in common with software development.* It's a specious comparison. Software development is only like bridge building if you're building a bridge on the planet Jupiter, out of newly invented materials, using construction equipment that didn't exist five years ago.
Traditional bridge-building engineering disciplines are based on God's rules-- physics. Rules that have been absolute and unchanging for the last million years. Software "engineering", however, is based on whatever some random bunch of guys thought was a good idea in the early 1980's. We don't have the luxury of working within a known universe. God didn't invent x86. That makes the comparison with traditional engineering disciplines tenuous at best. More than half of everything I know will be obsolete in ten years; can any civil engineer say that?
In "Computer Science" is Not Science and "Software Engineering" is Not Engineering, B. Jacobs proposes that software is more like math:
So, if physical engineering is applied science, but software design does not follow the same pattern, then what is software design? Perhaps it is math. Math is not inherently bound to the physical world. Some contentiously argue that it is bound because it may not necessarily be valid in hypothetical or real alternative universe(s) that have rules stranger than we can envision, but for practical purposes we can generally consider it independent of the known laws of physics, nature, biology, etc.The most useful thing about math is that it can create nearly boundless models. These models may reflect the known laws of nature, or laws that the mathematician makes up. Math has the magical property of being able to create alternative universes with alternative realities. The only rule is that these models must have an internal consistency: they can't contradict their own rules. (Well, maybe they can, but they are generally much less useful if they do, like a program that always crashes.)
Software is a lot like math, and perhaps software is math according to some definitions. The fact that we can use software to create alternative realities is manifested in the gaming world. Games provide entertainment by creating virtual realities to reflect actual reality to varying degrees but bend reality in hopefully interesting ways. A popular example is The Sims, a game that simulates social interaction in society, not just physical movements found in typical "action" games.
The hypothesis that software is mathematics is certainly more credible. But like Rory, I'm not even convinced that math and software are all that similar:
When I was growing up, I remember hearing people say things like, “If you like computer programming, then you’ll love math.” I always thought that these people were absolutely nuts. While there is something intrinsically similar about certain types of math and computer programming, the two are different in many more ways than they are similar.With math, and I’m not talking about the crazy number-theory math philosophy “Do numbers really exist?” side of things, but with the applied stuff, there are correct answers. You’re either correct or you’re incorrect.
With coding, the best you can hope for is to do something well. With so many different ways to effect a single outcome, it’s up to some very right-brained sensibilities to determine if you’ve met your goal, as there isn’t anybody (except [another more experienced developer]) who can tell you if you’re right or not.
If you ignore your right brain, and I’m talking generally about abstraction and aesthetics, then you can slap some code together that might work, but it also might be one hell of a maintenance nightmare. If you focus only on the right brain, you might have something that works, but is so utterly inefficient and personalized that you’re the only person on Earth who could make sense of the code and maintain it.
Unlike math, software can't be objectively, formally verified to be correct. Or even good, for that matter.
Software development is unquestionably a profession, but I don't think we can learn as much from the fields of mathematics or traditional engineering as is so often assumed. However, we do have a lot to learn from ourselves. Disseminating best practices to other developers is our biggest challenge, not adapting processes from unrelated industries. I recommend reading through this recent interview with Steve McConnell for his thoughts on how much the field of software development has advanced in the last 10 years-- and how to keep advancing.
* However, it is fun to build bridges in software!
Posted by Jeff Atwood View blog reactions
« Blogging about Blogging On Managed Code Performance, Again »
>"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.
mike on May 23, 2005 12:08 PM> 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.
Jeff Atwood on May 23, 2005 12:44 PMYou may like this quote on River Engineers:
http://exold.com/quote/river-engineers
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.
Chris B. Behrens on May 23, 2005 02:19 PMI 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
>> 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
http://www.amazon.com/exec/obidos/tg/detail/-/0679760210/
Jeff Atwood on May 24, 2005 08:17 PMInteresting 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
Punky on May 18, 2006 07:02 AMActually, 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
Joannes Vermorel on March 13, 2007 06:57 AMThis bridge has nothing to do with software development and that's just plain common sense.
ghost on March 30, 2007 12:10 PM--
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.
--
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.
Mark Jones on October 22, 2007 08:16 AMThis picture of this bridge they built is magnificent! It is a truly remarkable picture and bridge! WOW!!!!
Veronica on November 6, 2007 05:05 PMIt 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.
Montana Rowe on December 12, 2007 04:09 PMI 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.
Steve on January 25, 2008 03:15 AMhahahahahahahahahahahahahahahahahahahahahahaha
Man on March 10, 2008 08:00 AMomg i love this website it is so cool i just love it
i like guys
i have everything a girl has
even a boyfriend
and im a guy
i hate my life
im so emo i play with a rubrix cube during class
and cut my self with it
everyone hates me
i am a guy who likes guys
my brain is retarded
who else here likes guys
cause i do
and im coming out of the closet
message me
at www.imafaq.net
please talk to me
im lonely
i like guys now
cause all girls hate me
girls are yucky
please talk
i live in colorado
| Content (c) 2008 Jeff Atwood. Logo image used with permission of the author. (c) 1993 Steven C. McConnell. All Rights Reserved. |
Subscribe in a reader
Subscribe via email