May 22, 2005
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
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:
It's not engineering, it's not science.
Is it math?
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.
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"
Megaprojects and Risk
"Many projects have strikingly poor performance records in terms of economy environment and public support."
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.
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.
This bridge has nothing to do with software development and that's just plain common sense.
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... ""
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.
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.
I'd say that software engineering is more like writing a novel or essay. I'd say it has more in come with Linguistics than Math or 'Real' Engineering.
There are multiple ways to do Task A in a program as there are multiple ways to write Paragraph A in a story. Writing usually has some sort of syntax that it follows. Programming languages also enforce a syntax.
There are some exceptions but even those are covered in software engineering when we decide to design our own scripting language for our program which is ultimately parsed by a syntactic language anyways.
When we read source code, we read it top left to right and go continue on the next line, left to right, until we get to the bottom. (generalization, of course). Sometimes we jump around to follow the flow of the calls. Literature is like that as well. Some literature or source code is very simple and flow into each paragraph or function seamlessly. Other types of literature force the reader to jump around, as does source code.
As with the logic, one can write out a novel about math. We can write out math and express it in words. If the literature doesn't specify how to process the math, we have a general idea on how to process it. X = X + 1 means we take X and add 1 to it. However in a book about math, '+' could have been defined as substraction. We can do the same in software engineering.
With so many different ways to effect a single outcome there is only one best answer; mathematically determined to be the most efficient. Software engineering is measurable; running code can be optimized. What distinguishes civil engineering from practical engineering is not the nature of the solution but the specificity (and relative elasticity) of the requirement set.
I need a two-lane highway bridge across this river at this location to support up to 20 metric tonnes concurrently in each direction at up to 200 km/h implies a larger set of knowable facts (substrate and construction material properties, climate history, ...) which is distinctly different from we need a faster way to process credit card transactions.
Software engineering is engineering; those who choose to declare it an art have chosen to ignore the physical realities of the processor. Software requirements definition is certainly not engineering, hardly a discipline, looks like an art, and intrudes the realm of pure magic.
This is a wonderful discourse, much like the ones that happen in software design sessions! Obviously there are no absolutes here, wrong or right.
I agree with the comments about the engineering disciplines facing many of the same challenges as software developers face in terms of the torrent of changes brought about by the relentless expansion of human knowledge. I believe, however, that the lack of predictability (and sometimes reliability) in the software process can be compared to the challenges of the bridge builder IF you impose the condition that the builder will have to use materials whose characteristics and provenance that are unknown, and will have to invent and build many of the subassemblies that will be used to actually construct the bridge.
Even in the case of web applications, much of the software developer's challenges come from having to explore the performance, reliability (or lack of) and behavior of an enormous stack of technologies on which to base his application. (For now, we can ignore the very real challenges of building software to satisfy whims instead of requirements.)
Even in the very early days of non-mainframe development, your code had to be based on the (often poor) assumption that the functions you invoked in your code actually would behave as documented. What we consistently underestimate is the accumulated instability of the many layers of technology that underpin even the simplest application software.
If you were an engineer you should know that software can be objectively, formally verified to be correct
Software is based, at the very bottom, on bits, and they are entirely well-defined, objective, and determinate. Pure logic is as solid a foundation as can exist. The higher-level rules that follow are not well known. But it would be odd to suggest they never will be better understood. It has only been about 50 years. Even at the current state, the essential consistency of the medium allows substantial and detailed manipulation.
And looking at it from the other end: engineering is, roughly, assembling functional (ie. useful) parts to make functional wholes. Or slightly closer: assembling pieces by knowing/understanding their properties to a good degree, and using experiment here and there to fill particular gaps. When you build a web-app, for example, that is exactly what you are doing.
Certainly, software has special characteristics, but overall it is more engineering than not.
What I see missing in the comparison between building a bridge and software development is that the actual construction of the bridge is in most cases the shortest part of the project. Long before anyone starts construction they begin with an initial idea, then there is multiple reiterations of survey, design and review. This allows the engineer to make sure the bridge will meet the current and future traffic needs. In other words they begin by gathering requirements, then create their initial design, have that design reviewed and approved by everyone and anyone impacted by that bridge (city officials, citizens, federal government, etc).
After the final plan is approved, then they determine the materials, labor and equipment needed. Only then do they begin construction.
Yes they do have design changes as well as other problems arise that change one of the project constraints. This is an expected part of any project.
My experience in software development has taught me that I need to spend more time defining the problem, gathering requirements and design before I begin coding.