Eng-Tips is the largest engineering community on the Internet

Intelligent Work Forums for Engineering Professionals

  • Congratulations waross on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

What have we lost/gained 8

Status
Not open for further replies.

gaufridus

Mechanical
Jul 20, 2005
59
0
0
GB
Looking at thread 769-137240 reminded me of something that we used to do some years ago (late 1960s/early 1970s): I spent some time as an industrial engineer, in our office we had a calculating machine - huge desktop thing, mains electricity powered, nixie tube display etc. In lighter moments we used to have races - someone would write down a list of numbers and two people would race to add them up. One on the calculator thingy and the other person add them up in his (her) head. The mental arithmetic person would win more often than not. Today, when confronted with similar sums the first thing we do is reach for our calculators.

What have we lost or is it really a real gain allowing us to free our brains for other things?

What do other (older) folks think and what do the younger generations feel?

What other time saving devices have changed our working lives?
 
Replies continue below

Recommended for you

Would and could, but shouldn't.

We used to have a general manager like that, able to crank PDE solutions at age 70. He was quickly blindsided and broadsided into retirement by GMs interested in the bottom line.

TTFN



 
I am a younger engineer (5yrs out of school) so I can't speak to how things use to be in the old days. I think technology is a good and bad thing. The good is that you can use a program such as mathcad to perform calculations and limit the possibilities for errors along with present the design in a format much better than my chicken scratch. The bad is that now everyone thinks that they can design things with programs and templates. I have noticed that some people will automatically switch to using a program such as a FE analysis program to design something as simple as a single tier anchor wall. I think that before anyone uses a program to design anything they should be forced to show that they can perform the same calculation by hand (or at least a dumbed down version), and be able to show they understand where the differences from the hand calculations and the program come from.


I think that what has been lost is the ability to differentiate between people that can design and people that can't design. Let face it there are a great number of people out there with a degree that just plain and simple do not have the ability to be a competent design engineer. A degree and a license doesn't make a designer, it is just what is required to show minimum competencey. Minimum competencey and a black box computer program, that you do not understand what is happening, will surely produce errors.

 
There's really nothing new in that. 30 yrs ago, we were running SPICE on a time-shared computer over a 300 baud modem. And the EXACT same comments would come up about engineers who couldn't tell if the SPICE results were correct or not.

TTFN



 
IRstuff,

I remember collecting SPICE prints from the VAX cluster at university. Usually about 20' long on fanfold paper, each sample point being an 'x' or '*' character printed using a ribbon bereft of ink. Terrible things to interpret! pSPICE made things much nicer, apart from the data-munching virus on many of the lab PCs.


----------------------------------
image.php
I don't suffer from insanity. I enjoy it...
 
What! You got printouts?!!!




actually, we did too, but we had to download the file from the time shared computer and print it locally.

TTFN



 
I once was asked to check a very complicated "rail-structure interaction" analysis for a long, multi-span railroad bridge. The engineer did the analysis using the latest and greatest software with all the bells and whistles. The rail clips were modeled using nonlinear springs. The deck, bearings, piers, and even the pile foundations were all carefully simulated. The analysis filled several binders. There were colorful graphs and charts all concluding that there needed to be an expansion joint in the rails.

It took me only 5 minutes to check all of this. I just took the length of the bridge times the coefficient of expansion times the temperature change and got the same answer. The engineer failed to step back and remember that the axial stiffeness of a bridge deck is usually many, many times greater than the bending stiffness of piers. I agree with MrMojito - if there were no computers, this engineer would probably would have done something equally screwy.
 
yep... there's student in my son's class, when confronted with my son's volcano project, that used a smoke generator piped in from the bottom, exclaimed, "That's too technical."

TTFN



 
I read IRstuff's reference to log tables, and agree somewhat, but there is an advantage to understanding the basic origin of some of these things.

Using logs to manipulate number in symbolic math equations is all you need to perform many tasks, but what about understanding the underlying principle of using sticks of wood to perform multiplication.

The underlying principles are hidden to someone using the log table, but that underlying principle may be the creative key when it comes to solving new problems or solving old problems in new ways.

We never know what’s going to be useful.

I'm a licensed airplane mechanic and that's what I did part of the time going through school.

One night we were doing an engine change on a fairly complicated turboprop aircraft. This particular engine relied on all sorts of mechanical monkey motion to operate and it took quite a bit of rigging. One of the required adjustments was a serrated plate that set the angle of an arm within certain limits. No one had a protractor.

I was a student then, and I knew that if I traced coffee cup circles and folded them a certain number of times I could definitely say this wedge of paper represents X degrees and this wedge of paper represents Y degrees. I adjusted the plate between the two angles and knew for certain I was within limits. The engine checked out fine on run up.
We got the aircraft back on the line for morning flights because we didn’t have to wait for day shift to go buy a tool.

You might want to argue dimension calibrations issues, but as a responsible and experienced A&P, I had no trouble signing for my work.

We cannot keep everything in our heads but I am very hesitant to discount the value of any understanding.


 
I don't think that that's the issue. There are, and were, always people who can't or won't understand legacy developments and theory. They were around when the Greeks first worked in geometry and they are still around.

As Pogo observed, "we have met the enemy and they are us." Humans, as a whole, are simply not interested in in math and science. They don't understand the desire to know, and learn, and label those who seek knowledge as "geeks" or "Mr. Peabody's."

Regardless of the "tool," in question, there will always be those that fail to understand the tool and its history.

TTFN



 
I worryingly find that many of the above posts question the fallibility of computers - Surely these things are infallible!

Seriously though - I've never discovered an actual computer error. I have discovered many many input errors and a great deal of inappropriate modelling. I would have thought that junior engineers would be better at this stuff, but I've not seen the evidence to support this.

We would probably all agree that computer analysis needs to be checked, but how do we do that without recourse to 'old' techniques.

As a structural engineer I possibly have the advantage that a proportion of my design work is still done using hand calcs, so the ability is not truly lost.
 
I don't remember the Pentium bug.

However, most bugs and viruses, worms, etc. do exactly as they are written.

I have also found that most of my codes do exactly as I have coded it. Unfortunately, the way I coded it is often not what I was hoping it would do - but that is another thread.

With regards to computer error, they do happen. Many people include poorly written code that do not function as they wish under "computer error" when it should be "programmer error". Yup, this is me.

Or, they don't like the way a piece of code is written (because it doesn't work the way they think it ought to), and call it computer error. Yup, this is my users/clients.

Or, they make a mistake (either in coding, data entry, end user usage error), and call it a computer error. Yup, my users/clients are sometimes as dumb as me.

A true computer error would be, for example:
- failure due to overheating (external heat, not computer generated heat) - the space heater too close to the chassis
- magnetic corruption caused errors - I have no idea where the magnetic source was, but I am pretty sure it caused it :)



 
The Pentium bug I believe hit some of the early pentium chips and was to do with floating point calculations. There was a scare at the time that calculations done using those chips would be in error. We had, I think five pentiums at the time and many 486's.

As a check we ran the analyses done on the pentiums through the 486's and found no errors at all. Maybe we were lucky. We did do 'sanity check' calculations anyway and they had not indicated any gross errors. But that is of course the point - We only check for gross errors. There are not suitable means of checking the detail which do not rely on the very same technology!
 
As a former professional software developer, I have produced my share of "pentium bugs".

In truth, it is I, the programmer, who is at fault, and not my "computer".

That thing with the magnetic corruption, that was not me - I blame that on the "computer bug".
 
I remember one Engineering Manager who managed to create that most useful of objects, the write only memory.

Killed the chip stone dead.

Ho hum.

Couldn't have happened to a nicer chap...
 
Status
Not open for further replies.
Back
Top