Can Engineers be Replaced by Robots?

For robots to be programmed to do engineering design, they would first be fed all the code information. That is easy, but AI would need to be amazing if it were to compete with humans on design (unrelated to codes and science). We are not there yet, and likely not for 50+ years or more.

Science and the building codes provide minimal information that is helpful to solve a particular problem. This is obvious to me as a practicing engineer so I get surprised when asked by some “what do you mean the code allows flexibility”, or “how can you say the code is of little importance”, or “I don’t understand you when you agree that the code is huge in content but will never help solve 95% +of problems we face”.   Allow me to explain why engineering has little to do with codes (yes the code and science portion can replace engineers - but that is a small part of us). 

“But they (computers) are useless. They can only give you answers.” (P. Picasso)

There are engineers (mostly academics who think wrongly that we are applied scientists) that actually believe structural engineering is just about stress and strain - (ie. about science).  Let me respond to the main question about how engineering decision making is not procedural and can not be within codes by asking another question...

What do codes say about designing a simple steel beam?

Codes tell us not exceed 0.9 Fy Z for moment checks and something else for shear and that is about it.   Codes do not say anything about the following...

  • what is an optimum spacing of beams?

  • how do I weigh economy vs efficiency -in other words should I use a lot of the same beam or optimize every beam for diff spans

  • should I consider camber and how to evaluate cost of camber vs increase size of beam without camber

  • constructability - should I make sure the girder is as deep or deeper than the beam even if the girder is a small span

  • should I evaluate the vibration of the beam

  • should I allow for shear tabs instead of double clips angles at the ends to save money in the details

  • while I am designing a beam to girder connection of the same depth, should I verify the connection works with a double cope by doing shear rupture and block shear calcs

  • should I verify the studs should be a max of 1 per foot, or go to 2

  • should I size the beam to be not composite

  • how do I evaluate costs of studs, etc

  • do I feel comfortable with a 1" deflection even if the code allows it for this 30ft member or should I stick to my arbitrary 0.75" I made up

  • should I evaluate the ponding of the concrete and add additional dead load when the beam deflects

  • is a wide flange the best solution for this or should I consider a channel instead

  • I decide for this beam I am unhappy about a previous job where I cambered the beam 1" and the tolerance the fabricator is allowed increased that to 1.5" and the SC connection provided some rotational restraint at the connection, so the camber didn't come out and those damn studs were actually sticking out of the top of concrete at midspan - so I am not going to camber that much again!

  • I don't trust the code deflection criteria and invent my own

  • what is my min percent composite action or max stud per foot or min length to use camber, etc

  • when is it a good idea to just optimize a beam for efficiency (code stuff), if I was designing the smallest possible beam it could have 3" of camber and 4 studs per foot!

  • should I use ASD or LRFD, does it matter, when does it matter and how or should I stick to my old ASD 89 green book and say to hell with 2005 and omega factors

  • what should I use as a max live load deflection when supporting CMU or Brick walls, L/600 or L/900 or ?

  • why am I designing steel in the first place, should we consider concrete or wood or ??? for this beam

  • am I comfortable assuming this beam is braced to 1.5" metal deck (parallel) or and should I check lateral torsion bucking with the wet concrete loads

  • should I assume that there is a true pin at the shear connection, or is there some rotational stiffness there. If so can I get relief from not meeting the code live load deflection criteria – sure why not.

  • can I assume the beam is fully braced if the top flange if supporting a wood framed floor with joist hangers and how do I evaluate whether a joist hanger can brace my steel beam effectively

  • why did I just check shear yielding when shear yielding never ever controls the shear strength of the beam, what a waste of time but this was something I learned in school, so I will procede to check rupture, etc ,etc

  • do I need to check block shear of a beam web when the cope is less wide than the dist to the bolt line

  • what should I be optimizing when design a beam and how do I prioritize efficiency, economy, connectivity, constructability, deflection camber and stud count

  • etc etc

I can go on this forever!  The code says nothing about these questions.  So my point is - even in the design of a simple beam, the code (or computer or Robot) plays a small role! If we extend that to the infinite number of problems we face than we will see the code (programming code information) is of importance on a small fraction of problems.  So again...the code helps a little but for the most part we are on our own.  

Robots will take the 80% of the codes and science part of engineering soon, and already have to some extent, but not much beyond that. Humans can just decide to choose wood instead of steel and for no reason whatsoever.

Humans create the questions to answer too, not just answers to questions.

What We See Depends Mainly on What We Look For

 What we see depends mainly on what we look for.  [John Lubbock, British banker, politician, naturalist and archaeologist]

If this is the case, what precedes this?   What should we look for?   This is why experience is so important in engineering.  Determining what to look for is about prioritizing things we should look for and things we should ignore.

To know what to ask is already to know half. [Durant summarizing Aristotle]

Since engineering, like art, is the conscious use of skill and creative imagination, in addition to the ability to sift through many parameters, the only way to create a solution is to ignore things we can ignore and spent time on the things we need to spend time on.   The only way to do this is to actively look for things that matter on our projects.

How do we improve our codes?

There are too many useless, confusing, burdensome, and disproportional provisions in our building codes.   Useless provisions are those that are redundant or those provisions that are obvious.   Confusing provisions are usually those that are overly prescriptive and difficult to understand due to excessive descriptive language.  Burdensome provisions are those that are inappropriate and unnecessary for a particular structure but are required none-the-less.   Disproportional provisions are those that are unnecessarily exact and not proportional to the assumptions and uncertainty inherent in structural design.   How do we address this problem?   Are we trying to perfect our building code far beyond our practical needs of providing safe structures?  If so, how do we stop? http://structuresworkshop.com/blog/2011/10/16/9-improve-the-codes/

The Truth of Structural Design

There seems to be a progression of understanding as one designs structures. At first, as college students, we have well defined analytical techniques that appear objective and clear (there is truth). Later we learn this idea of structural design is naïve. What we do is not clean. As the years go by, there is an improvement of the design of structures which combines the simple objective science with more complex subjective decision making requiring sound judgment (heuristics). There is not truth anymore, what is left is "good enough". Problems encountered by the structural engineer are complex and nuanced and require experience and judgment to better sift through the multiple design ideas. If there was a progression in the mind of a structural engineer, I think it is similar to the one that the philosopher Friedrich Nietzsche wrote about in “Twilight of the Idols” (see MSC article). While Nietzsche was generally referring to raising the human spirit to a higher level, it is similar to my experience, going from 1 to 6, as a structural engineer over the fifteen years:

1. The ”truth” of structural design – is attainable for the sage, the pious, the virtuous man.

2. The “truth” of structural design - unattainable for now, but promised for the sage, the pious, the virtuous man.

3. The “truth” of structural design - unattainable, indemonstrable; but the very thought of it - a consolation, an obligation, an imperative.

4. The “truth” of structural design - unattainable? At any rate, unattained. And being unattained, also unknown. Consequently, not consoling, redeeming, or obligating: how could something unknown obligate us?

5. The “truth” of structural design - an idea which is no longer good for anything, not even obligating - an idea which has become useless and superfluous - consequently, a refuted idea: let us abolish it!

6. The “truth” of structural design — we have abolished. What world has remained? The apparent one perhaps? But no! With the true world we have also abolished the apparent one.

Thus, we have abolished truth in practice even if we pretend it still exists in school. Good enough is enough in practice (i.e. a good enough design decision = a correct answer). That doesn't make it easy, “good enough” is actually very hard. It is apparent in this progression the great extent to which the individual engineer can influence the design. I have found that the design of structures is less dispassionate and logical than I used to earlier in my career. There are no clear-cut answers to the complex and diverse problems we face. This is not to diminish the role of analytical tools to assimilate knowledge of phenomenon, it is just that it is simply not enough.

(E Nelson,  portion of MSC Twilight of the Idols)

Published “Twilight of the Idols” Modern Steel Construction Magazine

A Recent Day, Smelly Braced Frames

Engineers have to straddle many worlds.  We may find ourselves one day designing steel connections, then meeting on a new job to discuss appropriate structural systems, then doing some BIM modeling.   As we grow into project managers we may find ourselves writing emails and attending meetings possibly more than doing engineering calculations.   We use our judgement more and more to know where to start a problem and what to ignore.   There are no typical days.  I had a day recently where one morning I designed all the braced frame connections on a job and then in the afternoon attended a project review at an architectural college.  The student project consisted of spreading toothpaste on the wall and discussing how smell should be incorporated more into our built world.   That is right, smell - and objects should contain smell.   For some reason at that moment, it made sense.  I thought about what the brace frame connection smelled like that I designed that morning.   Not sure why, but I thought of that premade potato salad with that overly smelly mayo/mustard dressing.

Dreams, Mistakes and Uncomfortable Decisions

I woke up at 3am today again.  It was the same dream, or similar dream to what I have been having over the last decade.   I forgot to check something.  I missed something in the code or I missed something more structurally egregious.    This latest dream was something that surprised me because I was actually wrong, I did check it!   I came to work early to discover that I did check this beam for additional load due to this or that, so no big deal.   Sometimes my dreams help me, I get a sort of eureka moment and I am better able to tackle such and such problem.   Other dreams are harmful, and they make me nervous and anxious and I can’t get back to bed.   There are two main themes to these dreams:  (1) Mistakes, whether real or imagined, and (2) Uncomfortable Decisions.  Uncomfortable decisions are by far the most common of my dreams.  These are engineering decisions that are made without the best understanding of how the part or system will perform (very common daily decisions when unique details or structures are developed).  This is why engineering is a profession.   We need to pull things out of a hat sometimes and live with them.  Part of the anxiety of a structural engineer is that we are solving problems that never existed before, we are inventing something new.    Yes, physics doesn’t change, but that is about the only thing that doesn’t.   Every building has traits that no other building in the world has, and have we verified everything?   Of course not.   But have we verified everything we know how to verify?  After all the calculations are applied, we still have to make a decision about whether it should be built a particular way or be changed.  Eventually we have to say yes, “no exceptions taken” and live with it the rest of our lives.   Crazy things get built and amazing engineers are the creative force behind all of them.  How many structures out there do we lose sleep on?  Maybe 2-3 per year on average?

Structures Workshop invests in New Software

We bought 4 licences of Tedds to help us supplement our in-house calculation packages.  In addition, we bought 3 licenses of Bluebeam which help us easily mark-up PDF drawings and coordinate drawings in real time online with multiple users (it is Adobe Pro on steriods).   We are also considering buying SDS/2 Connect after our 30 day trial to help us coordinate 3d steel connection design within Revit.     These new programs, along with out current licenses of Etabs and Revit allow us to be at the state of the art in the engineering community.

Engineering Beginnings

Future Engineers?

Future Engineers?

When I was about two-three years old, my parents were concerned because I did not talk. I struggled in social situations and preferred being on my own with building blocks or trucks. I didn’t have a picture of myself, but here you can see my 3 boys doing essentially what I was doing – playing with things that have wheels.  Anything with wheels or toys for building were the most appealing.

I learned much later that I was considered a "non-verbal" thinker. I did not do well in kindergarten or first grade and flunked second grade.  I was given speech therapy and slowly caught up to others my age, but it really was not until high school that I felt comfortable reading and comprehending what I was reading.  What I lacked in social skills, writing, or reading was offset by considerable skill in making stuff. I built pretty amazing castles and boats out of wood blocks and LEGOs. While upbringing specifics will obviously vary from Engineer to Engineer, I have yet to meet one who wasn't the master of LEGOS on the block.

Engineering predates Science

We were designing and building things long before we had a “scientific” methods and mathematical solution techniques – and we still do today.  We can actually do engineering without science (Pantheon is an example), but science does indeed help and is absolutely necessary today.  A calculator helps too.  Did we need to wait for mathematical understanding of a hanging chain before we could build catenaries?  Of course not.   We didn't need to wait for Galileo and Bernoulli to create architecture.   We didn't need Euler to design columns.  This “pre-science” type of engineering is design and it is still 90% of what we do today.  Have you witnessed the architect August Perret's Church of Notre Dame du Raincy?   Were the methods of proportion used in the past flawed?   Sure.   Did they work?   Sure, sometimes.  Are current state-of-the- art methods that are good at mimicking nature still flawed?    Absolutely, less so, yes, but certainly flawed.  We as structural engineers should recognize that while science and math are critically important to what we do, they do not define us - and history tells us, they never did.  How can we be defined as applied scientists when engineering predates science?

Art Without Craft?

The New York Times published a bunch of wonderfully funny "doodles" by the artist David Shrigley.   Here is one of them:

‘‘I’m not trying to draw badly,’’ says Shrigley, who graduated from the Glasgow School of Art. ‘‘I’m just trying to draw without any consideration of craft."

I wonder what architecture (or engineering) looks like without consideration of craft.

The Stone Pulls the Horse

Newton's Third Law We think of this as F = F, or "for every action there is an equal and opposite reaction", but Newton expressed this differently than the way we learned this in school.   In his work Philosophiæ Naturalis Principia Mathematica, first published in 1687, there were no equations in his laws, and they were grounded in concrete reality.  He added a physical description one could envision in the mind, rather than the abstract way we think of it:

If you press a stone with your finger, the finger is also pressed by the stone. If a horse draws a stone tied to a rope, the horse (if I may so say) will be equally drawn back towards the stone: for the distended rope, by the same endeavour to relax or unbend itself, will draw the horse as much towards the stone, as it does the stone towards the horse, and will obstruct the progress of the one as much as it advances that of the other. [Newton, 1687]

Why didn't my teacher ask me how the little stone can pull a horse with as much force as the horse pulls the stone?   "It is the tension in the rope!" would have been something fun to discover in high school.  Instead, I just read "action = reaction".

• Settings >> Advanced >> Code Injection >> Footer