engineer/designer vs builder/laborer

[John Coloccia]

The problem is that you see this kind of stuff in everyday engineering work, but no one ever writes about it. Back when I was a respectable engineer, you could have followed me around for a day to see all the idiotic designs out there. The problem is that very few engineers actually know how to make anything, and even fewer have any sort of interdisciplinary skills (i.e. the mechanical engineer that knows about electronics, he software engineer that knows about mechanisms and structure, etc etc) so you end up with situations like (and I've seen ALL of these and lots more):

1) mechanical engineer designs a hollow metal object with no seams (how do you build it?)
2) mechanical engineer crams electronics into a box without considering thermal load...I've seen things heat up enough to REFLOW solder...seriously.
3) software guy designs robot interaction in such a way that it's impossible to clear a fault without rebooting...they just didn't understand at all how operators used their equipment
4) electrical engineer designs board that can't be mounted....screw holes interfere with some mechanism
5) mechanical engineer designs mechanism that is easy to make but impossible to assemble (screws are buried behind other parts and are inaccessible)

I can go on and on and on and on and on and on. Here's a failure between software and user interaction. I won't mention the project but I worked on a project where an accident happened and some damage to a VERY expensive and practically irreplaceable item was done. Damage was in a non-important area, but regardless it triggered a review. Now the REAL problem was the guy holding the pickle (i.e. the emergency stop) failed to hit the stop button when the item started moving. There was a clear protocol of when motion was to be expected the test director said "motion expected" over the intercomm. The pickle operator hesitated when motion started, though, and asked "is motion expected?". That hesitation was enough to cause the damage. Now the REASON he hesitated was that every time you hit the pickle, management decided to conduct a witch hunt "review" of the incident, which was really just an excuse to chew out the guy that delayed the testing. Great, right?

But of course, none of this is the real problem, right? No...the REAL problem was that the software didn't ask "are you sure???" before issuing the command. Now, that wouldn't have helped anything here, but you can't have the real issue of incompetent management come to light, so down comes the order to put an "are you sure???" on all commands that could possibly cause any damage. Fine. The engineer in charge of that particular piece of software, a very good and experienced engineer who I respected, made a reasonable request. He simply wanted someone to provide him a list of commands that management felt was possible to cause damage. Well, of course no one would take responsibility for giving him a list....after all, you might miss one and then it would be YOU getting chewed out. Fine...he made it configurable and the default was to simply put this "are you sure????" on every command. The exact wording was something to the effect of, "Warning!!! Issuing this command may cause grave damage to the system!!!".

End result...the "are you sure" became a constant source of annoyance and was completely ignored. You just automatically click through it as though it wasn't there because it was EVERYWHERE. Oh, and the communication issue that caused the initial problem was never addressed.

On this same project, one of the processors I was working on started acting up. This thing was basically a little super computer and I was pretty much in charge of that software at that point...I think I may have just been promoted to Engineering manager, so maybe I was feeling my oats a bit. I poked around some and it didn't take me long to figure out that when I started doing some real calculations, the power supply was sagging and dropping out. I'm trained as software but I happen to be very comfortable on the electrical side of things, as well as mechanical...I don't care...I'll design and build my own boards, machine my own parts...whatever it takes (doing robotics for years means you just have to learn to do that to do your job). Anyway, it wasn't difficult to figure out there was something totally screwed up with the power supply, and I shut down the test. The deputy program manager ordered me to start the tests back up, and I told him to go pound sand. He was MAD. Now understand, all of this happens to be on an airplane....a very EXPENSIVE airplane with all sorts of expensive and delicate/sensitive things on board.

Anyhow, I got my way, mostly because they needed our team to continue the testing. A couple of days later we got a new power supply, I installed it and we where on our way. We sent the old supply back to the manufacturer for testing. These are big supplies....2kW@12v, or something like that, and we didn't have a clue how to test it on site. They plugged it in, attached a small load, and the thing immediately burst into flames....LOL. Culprit? Again, solder reflow from poor thermal management. If that had happened on the aircraft, it would have been a MAJOR problem. Deputy program manager came to me that afternoon and said, "We're always behind and we're always trying to rush, but you tell me to stop anytime, got it?"

Lack of communication is one of the biggest problems in the engineering world. You won't find much on designing things that are difficult to build because most of them haven't been built...it's caught before then and long forgotten. You WILL find a lot on communication problems causing major headaches.

Let's see...there was the satellite that slammed into Mars because they had a little snafu regarding metric vs standard measurements. That was fairly recent.

Have you ever seen this picture?

http://www.spaceref.com/news/viewpr.html?pid=15189

My company was contracting for Lockheed at the time on a completely separate project, but news travels FAST, so I saw pictures of this before news even got out...and I also heard the story how it happened. I haven't read the report so I'm not sure what's in it, and I don't want to contradict anyone so if I say anything different than what's in the report, just chalk it up to my bad memory and third hand information. My recollection, though, is that someone "borrowed" some bolts from an adapter plate that attaches the satellite to the tilt mechanism. The bolts attached the adapter to the tilt mechanism. Some time later, maybe the next day, when they got ready to tilt they noted that the satellite was bolted down and went ahead and started tilting....and the satellite, attached firmly to the adapter plate, slid right off.

Communication, communication, communication, and a management structure that makes it easy to do your job and communicate as opposed to punishing you at every turn.

[curtis rosche]

thanks John, i might quote you in my paper

[David Epperson]

The problem is that you see this kind of stuff in everyday engineering work, but no one ever writes about it. Back when I was a respectable engineer, you could have followed me around for a day to see all the idiotic designs out there. The problem is that very few engineers actually know how to make anything, and even fewer have any sort of interdisciplinary skills (i.e. the mechanical engineer that knows about electronics, he software engineer that knows about mechanisms and structure, etc etc) so you end up with situations like (and I've seen ALL of these and lots more):

1) mechanical engineer designs a hollow metal object with no seams (how do you build it?)
2) mechanical engineer crams electronics into a box without considering thermal load...I've seen things heat up enough to REFLOW solder...seriously.
3) software guy designs robot interaction in such a way that it's impossible to clear a fault without rebooting...they just didn't understand at all how operators used their equipment
4) electrical engineer designs board that can't be mounted....screw holes interfere with some mechanism
5) mechanical engineer designs mechanism that is easy to make but impossible to assemble (screws are buried behind other parts and are inaccessible)

I can go on and on and on and on and on and on.

Communication, communication, communication, and a management structure that makes it easy to do your job and communicate as opposed to punishing you at every turn.

I hear you John. I used to be a "Mechanical Engineer" - or a "Manufacturing Engineer", even a Project Engineer. Most of those positions boiled down to my being able to design and build specialized prototype devices - and sometimes to write the control programs as well, some wiring in there too.

I used to STAY in trouble for taking too long on a design - but I had a pretty good "Worked first time out" average going.

I was changing companies once and the engineer taking my place wanted to know how to seal some aging piping that carried molten lead (Pb). This was a 2 minute conversation and I mentioned re-machining the seal surfaces first - which was rejected as too time consuming, and skilled labor intensive. At which point I shrugged and told him to find something "like" soft copper that would fill the erosion voids and effect a seal. Apparently he didn't get the jist of why I said something "like" copper and went ahead and used copper - which shortly dissolved and filled a fairly large pit, as well as coated a large extruder drive gearbox with rapidly cooling lead - to a depth of around 3 foot.

But the best story I heard of was the original design for the Clinton Library in Little Rock (Which looks like a trailer with a 5th wheel hitch) - the concept people didn't want the 5th wheel hitch looking support - they wanted the entire building CANTILEVERED out over the river.
Luckily the contracting company told them to pound sand or go elsewhere. The 5th wheel hitch looking section alone cost a few million to fabricate I think - and the building still has to be re-shored and re-leveled several times a year. (There is aledgedly a full time drywall contractor on call 24/7 to repair the walls)

[Jim Rimmer]

There's a hotel/condo/skyscraper that was being built in Vegas that will probably be torn down and never finished. There is an argument between the engineers/architects and the builders. I don't remember the whole thing but it was a recent news story.

I googled Las Vegas building dispute. Here's a good link:http://www.vegasinc.com/news/2011/au...molish-harmon/

Here's another link to multile problems with the Luxor http://www.onlinenevada.org/luxor_hotel And another about a death ray from a Las Vegas hotel http://www.ar15.com/archive/topic.ht...&f=5&t=1096269

[John Coloccia]

This never would have happened if the Corleones were still around.

[Jim Rimmer]

Some of the folks here may remember the Ford F series pickup when they still had the twin I-beam front suspension. I had one, 1974 I think. The problem was changing the oil. The drain plug was right above the I-beams and there was no room to out a catch pan. So when you drained the oil it ran all over the beams and dripped off in several locations.

[Jason Roehl]

Jim, that's not a design flaw, that's a FEATURE--your twin I-beams get lubed and never rust.

John--are you saying that engineers are bad at communication? NAWWWWW... (I have a family full of them, and I started college in engineering).

Curtis, you could probably interview just about any large builder who regularly works with an architect and get a whole litany of examples.

Heck, there are plenty of times I want to strangle builders and/or their carpenters for putting something together and THEN calling us painters. Tomorrow I will be caulking and painting the exterior trim on a small room addition where I explicitly told the builder AND his worker beforehand that all the cuts on the manufactured trim they were using needed to be at least primed. I even left the paint the homeowner provided and a couple disposable brushes for just that purpose. I looked at the installed trim today and there is not a drop of paint on any of the new trim. I'll do my part tomorrow, but I also won't tell the homeowner that the trim won't last as long as it could have.

[Dan Friedrichs]

Back when I was a respectable engineer...

This was the best line of the whole thing

[Bill Edwards(2)]

Tonight, on Dr. Phil:

"Free thinkers", are they good team players?

This group says, "He** NO!"
This other group says "He** NO!"
Actually, everyone says, "He** NO!"

Let's pick another topic, Phil.

Tonight, on Dr. Phil:

"Craftsmen", are they good team players?

*sigh*

[Dan Hintz]

I'll do my part tomorrow, but I also won't tell the homeowner that the trim won't last as long as it could have.

Well, that's disturbing...

[Jeffrey Makiel]

Here's an interesting read...

http://en.wikipedia.org/wiki/Citigroup_Center

It resulting in NYC being put on alert as hurricane season was coming.

Jeff

[Brian Vaughn]

As a currently employed engineer, I would agree that engineers, to a large extent, have plenty of "book learning", but very little pratical experience. But thinking about a comparison, by the time I was out of college and into my first engineering job, a craftsperson would already have 5 years in their specialization. Now, they may be able to look at a certain situation and give you a more practical answer, but they've had much more time working on that sort of thing. HOWEVER, as has been mentioned, a mechanical engineer may not know all that much about programming a PLC, but they could (or should be able to) tell you how big a pipe needs to be in order to flow a certain amount of water without causing cavitation, or taking too much head loss. The point is that some of that knowledge comes from experience. I happen to be a mechanical engineer who learned to program a PLC when I had one that was incorrectly programmed and I had to fix it.

On the other hand, I work with craftspeople at my current job from at least 8 different unions (Sheet Metal Workers, Boilermakers, Electricians, Insulators, Carpenters, Pipefitters, Welders, Machinists, just to name a few) I could ask one of the boilermakers what the standard torque on a 1" bolt is, and he should know that sort of info, but an electrician will just give me a blank stare. A carpenter could tell me how many and what size scaffolds I need for a job, but don't know how to do the scheme check on the wiring once I get up there.

My whole point is that the engineer is supposed to be knowledgeble in a lot of different aspects of the job, and be able to take it from theory to reality, but we often find that what seems like a good idea on paper doesn't necessarily work in real life. But many times, I could hand that same piece of paper to one of the laborers and they couldn't tell me if there's something wrong with it either.

Personally, I've never tried to design a shaft through a moving gear, but I've some up with some crazy ideas on joining some of my furniture pieces that I had to go through a very specific sequence to assemble, or I wouldn't have room to put in some of the screws. It happens to the best of us, but going back to a previous topic, it's the people that can visualize all this, who can figure out how it's all going to work together, that are going to be the best designers.

But as for specific cases, more recently I had one where an engineer told some laborers to tighten a joint. The boilermakers looked at the torque and told him that if they did it that tight, it'd just make things worse, but he insisted, and sure enough, we'll be replacing that gasket come January. But I've also had boilermakers that insisted we use RTV on a very large opening, which I refused to allow because there was no way they could get the joint back together before it set. They did it anyway, and sure enough, due to the irregularities in the RTV layer, we now have a ton of leaks. Plus, they tried to tighten it down more to help, which resulted in fractures to the RTV and made things worse. It goes both ways.

I get feedback on a regular basis from laborers, in their specific knowledge area, and it's the engineers that listen to that advice and are able to incorporate and learn from it that will be the biggest successes.

[Jason Roehl]

Well, that's disturbing...

One might think so, but in this case, I'm not working for the homeowner, I'm working for the builder. I try not to bite the hand that feeds me, particularly going into winter in a down economy.

[Ryan Mooney]

The problem largely seems to fall into several major areas that I've seen:

1. Raw incompetence in primary sphere. I believe that this is actually rarer than people would like to think but I'm sure it still happens (as evidenced by multiple examples on this thread ).
2. Changing requirements. Engineer designs part A to work properly with part B, builder (or as often some management wank who has never actually designed nor built anything) replaces B with C and chaos ensues.
3. Engineers Disease. This is where the person believes expertise in discipline A yields corresponding expertise in discipline B. At a previous gig I worked with some EE's who were designing various mechanical and software components in addition to the electronics. Predictably this lead to innovative solutions like "aligning" antennas (with a 1/4 degree beam angle at 10 miles) with a compass and then cutting the mounting hardware exactly to fit back at the shop (worked just as well as expected).

If you haven't already found it check out the risks digest, its somewhat more oriented towards software failure but has a lot of delicious anecdotes about the intersection between design and implementation: http://catless.ncl.ac.uk/Risks/. The older editions tended to have more hardware related issues.

Another interesting list (containing some previous mentions) http://en.wikipedia.org/wiki/List_of_software_bugs
Most of these: http://www.soe.uoguelph.ca/webfiles/...gDisasters.htm would also apply. Google searching for "engineering failures" yields a lot of noise but still has significant signal..

To correct the Ford Exploder/Tire comment from Bryan, the real issue was related to my point #2 - the tires were designed to be run at a higher inflation, but provided a smoother (albeit apparently less safe) ride at lower pressures (in this case basically sales overriding engineering). Reference here: http://usgovinfo.about.com/blfirestone.htm - found via http://www.electronicsweekly.com/blo...est-mista.html. We had one of the affected vehicles, the (imho) retarded tire salespeople refused to mount another brand of safer tires but would only sell us the "approved" replacements. Yaah for litigation making things actually worse.

[Dan Hintz]

I would agree that fresh grad engineers, to a large extent, have plenty of "book learning", but very little pratical experience.

Fixed that for ya...

But thinking about a comparison, by the time I was out of college and into my first engineering job, a craftsperson would already have 5 years in their specialization.

My whole point is that the engineer is supposed to be knowledgeble in a lot of different aspects of the job, and be able to take it from theory to reality, but we often find that what seems like a good idea on paper doesn't necessarily work in real life. But many times, I could hand that same piece of paper to one of the laborers and they couldn't tell me if there's something wrong with it either.

Which requires a number of years of schooling before an engineer is considered knowledgeable enough to start working on projects... whereas a craftsman has enough knowledge to start working on simple projects almost from the beginning. After 10 years or so, both have plenty of knowledge and experience to handle complicated projects, so it all evens out.