>"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="https://exold.com/quote/river-engineers">https://exold.com/quote/river-engineers</a>;

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.

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"
https://flyvbjerg.plan.aau.dk/COSTCAUSESASPUBLISHED.pdf

Megaprojects and Risk
"Many projects have strikingly poor performance records in terms of economy environment and public support."
https://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:

https://composite.about.com/cs/bookspetroski/

To Engineer Is Human : The Role of Failure in Successful Design

https://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

https://www.amazon.com/exec/obidos/tg/detail/-/0679760210/

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.

--
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.
--
https://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.

--
https://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.

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.

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.

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.