Why We're Not Really Engineers

by Curtis Poe

In the book Surely You're Joking, My Feynmn!, Richard Feynman tells an amusing story of engineers showing him complicated blueprints and him pointing to them and asking "what happens if this valve sticks?"

The engineers were astonished. They pored over their blueprints and realized that they had a design flaw. What's amusing about the story is that Mr. Feynman was bluffing. He didn't know if he was pointing to a valve or not and assumed the engineers would gently correct his misunderstanding. By mere chance, a serious problem was averted.

In yet another anecdote I read, a contractor finished building a hospital but its opening was delayed because somehow nobody realized that they had forgotten to have phones in the building. Oops.

Today, these sorts of problems are less likely to occur because engineers, architects and others have sophisticated software tools which can alert them to potential problems. But what about "software engineers"?


13 Comments

Matt
2006-06-01 12:58:59
Interesting post. Thanks for the reference to Alloy. I have been doing software testing for a while now. Most of the companies that I have worked for are not actually interested in software testing or QA. They see it as slowing them down. So even the best tools will not get used.


Maybe I should try working at Boeing?

gary capell
2006-06-02 00:02:43
look up "pored" and "poured" in the dictionary, please? Unless the engineers spilled their coffee over the blueprints ...
Ovid
2006-06-02 00:21:25
Gary: Fixed, thank you! I sometimes tease people about their spelling and grammar and I deserve to be hoist on my own petard for that one.
James
2006-06-02 00:41:55
Why software engineering is fundamentally different
Ian Williams
2006-06-02 00:57:42
It's 'hoist by my own petard'. The phrase was coined by Shakespeare in Hamlet, where it meant 'blown up by my own bomb'.
Jeremy Jones
2006-06-02 04:52:48
Great post, Curtis. I'd argue, though, that we are engineers....or at least we can be. I spend my day split between working on an embeddedish application and a data processing server application. On the embeddish side, I'm working on integrating our app with a new piece of hardware. I spent literally hours just going over the existing code trying to wrap my head around it fully, beginning the mental design process for the integration, and checking any other "touch points" in the code base before writing a single line of code. Couple of interesting points here. 1) There wasn't that much code to go over, but I need to do things right. Not because imperfection is not tolerated. Because that's how I'm wired. 2) I've thoroughly tested my code and it's not even ready to go to QA yet. I would consider both of these points to be at least "engineering inclined" dispositions.


So, my point is the same one that James made by posting the link he did. We're a young discipline. We lack the maturity of mechanical engineering or architecture or .... whatever. We are also fundamentally different in that there is no physical building process and therefore a software design flaw can be cheaper to fix than, say, a bridge design flaw after the bridge is built. (Notice I said "can be", not "is".)


I'll have to look into Alloy. This may be a type of tool that pushes Software Engineering further along in the evolution of becoming a fully engineering compliant discipline in the traditional sense of the word.


Again, great post. Thanks! And thanks for the reference to Alloy.

Stiennon
2006-06-02 08:54:52
A few things "software engineers" typically don't have to worry about:


Differential equations
Partial differential equations
Taguchi analysis
LaPlace (Heavyside) transforms
Steam tables (dating myself)
All of Newton and Einstein
Maxwell's equations
Navier-Stokes
perturbation theory
physics
mechanics of materials
finite element analysis
thermodynamics
boundary layers
Von Karmen vortex streets
related rates (chemistry)
variation analysis
Fast Fourier Transforms
Vibrations
Acoustics
plasticity


just to name a few...

Stephen
2006-06-02 09:58:58
Didn't Shakespeare write "Hoist with his own petar" using neither on nor by? I agree, however, that the phrase is typically rendered using by.
JHi
2006-06-06 08:21:59
> Von Karmen vortex streets


It is Von Karman.


Yes, software engineers do not need to study materials and objects of the physical world. (Unless, of course, they deal with hardware, electronics, electricity, light, et cetera.) So what's your point?Mechanical engineers don't need to worry about NP-completeness, or cache effects, or error correction, or data compression, or cryptography, or parallel computation, or so forth. People deal with what they need to deal. One can of course define "engineering" to be engineering only if it deals with physical concrete things.


Vladimir Orlt
2006-06-08 10:13:51
Could engineering be... "the application of mathematics"?
That to me has always been its beauty... and software definitely falls in that category.
Javier Sanchez Galan
2006-06-25 19:48:31
Being a Computer Systems Engineering student on a polytech school its interesting and in times confusing.


You get along with different engineer students, mostly in studying the "common engineering majors" (Civil, Electrical, Mechanical) and in some time of your carreer someone from those majors will tell you sometime like: "Systems Eng (or Soft Eng) isn't an engineering at all! every engineer knows how to program and in fact you dont mess with FFT, strenght of materials, finite element analysis, Multi Body Dynamics ... etc"


I agree with Mike Tung (http://vcmike.blogspot.com/2006/03/engineering-software.html): "I say software engineering is fundamentally different from other types of engineering, because the field itself is still in its prenatal state" (hey we are building are houses since ever)


and with JHI: "One can of course define "engineering" to be engineering only if it deals with physical concrete things " (If you dont see it doesnt means it doesnt exist!)


In conclusion the truth is that soft eng is a step further from the common engineering (here im not trying to say that is better, im saying that is different!), because of the level of abstraction it requires to be understood and furthermost because it deals with people and/or code that people writes.

seven Amsterdam
2007-03-22 01:48:31
In the book Surely You’re Joking, My Feynmn!, Richard Feynman tells an amusing story of engineers showing him complicated blueprints and him pointing to them and asking “what happens if this valve sticks?”
I do not agree. Go to http://www.freeworkz.info/adjectival_Netherlands/disuse_Holland/seven_Amsterdam_1.html
Al Brown
2008-04-10 09:28:58
Vlad wrote:Could engineering be... "the application of mathematics"?
That to me has always been its beauty... and software definitely falls in that category.


Vladimir Orlt | June 8, 2006 10:13 AM


But if physics translates to electrical engineering, and chemistry to chemical engineering, then what form of engineering does political science or economics (dismal science)?


I think the latter must be estimators and the former either in contracts or the guys who think they actually bend space-time by the length of a line on Primavera Project Planner.