General Engineering Introduction/Scientist

Engineering Science
The similarities between engineering and hard sciences are striking. Engineering sciences are mathematical and exact within prescribed limits. page 10 But the purpose of engineering science is not to record "laws of nature." Engineering science states relations among measurable properties that allow mathematical analysis. Engineers form abstract concepts independent of science. These concepts serve as a framework within which technical problems can be analyzed. page 11

Modern engineering science began in 1749 in Mézières France. Military engineers studied algebra, geometry, trigonometry and engineering mechanics. In 1794, the Ecole Polytechnique was established in Paris. Students went there for two years and took core classes that were primarily math. Graduates went to schools of application and specialized in artillery, military, navy, bridges, roads and mines. From this time on, engineers have enjoyed high political status in France. Some schools in the US followed this model including the US Military Academy and Rensselaer Polytechnic Institute. page 74 Today most engineering disciplines are evolving along this scientific model. Some classes in mechanical and civil engineering date back to these times.

Most English and US engineering institutions did not initially follow the French scientific model. Instead they followed what has come to be known as "Art and Practice" which evolved out of English guilds. The drawbacks of English engineering became apparent during WWII. The US military preferred to work with Scientists. Engineers of that generation were entrenched and drifting towards technology. Scientists were the ones making both marginal and significant technological advances. Ten percent belonged to unions in 1957. After the war, the US began to emphasize engineering science.

The science emphasis began with the creation of the National Science Foundation in and 1950 and was solidified by the sputnik crisis in 1957. Federal dollars poured into research organizations and universities that promoted science, not engineering. By 1961 the changes were beginning to be noticed. And they were not positive. Recent engineering graduates were criticized for "unwillingness and inability" to consider a complete design problem. They would only tackle the fully specified problems that could be solved by analytical methods. Young engineers tend to consider problems that don't involve calculus to be beneath their dignity. (MIT April 1961 report in Journal of Engineering Education called "Report on Engineering Design.") What was lost in the transition to engineering science was labeled "../Design/."

Scientist Versus Engineering
An engineer is a jack of all trades, master of none. The engineer is one of the few remaining renaissance profession.

Here are some reasons why engineering and science are called "mirror-image twins" by the historian Edwin Layton:


 * Engineers work together. Scientists differentiate.
 * Engineers think about which projects they want to be on. Scientists think about student papers, presenting, publishing and begin attending journal clubs.
 * Engineers share success, share failure, share materials. Scientists view each other as "colleges" (competition).
 * Engineers are encouraged to ask for help, to harvest the group mind, to present problems without solutions. Scientists are trying to do original individual work and learn to ask questions that can not be criticized later as "help".
 * Engineers search for sound bytes and worry about questions derailing presentations. Scientists work on projecting confidence, certainty and are not afraid of talking over the heads of the audience.
 * Engineers begin thinking about where they are going to work. Scientists begin thinking about what grants they are going to apply for.
 * Engineers jettison mistakes rapidly. Scientists hold onto mistakes, waiting for formal proof they are wrong by a peer.
 * Engineers tinker with stuff. Scientists tinker with ideas.
 * The ultimate Engineering success is profit. The ultimate Scientific success is recognition such as a Nobel's prize.

Engineers that get a doctorate have to deal with this scientific attitude. Many loose the engineering attitude.

An engineers life is rich. The engineer deals with everything:
 * Philosophy: Truth, Beauty, Goodness
 * Understanding: Intuitive, Empirical, Analytical
 * Service: Species, Families, Ourselves
 * Emergence: Kludgy, Elegant, Profitable
 * Scope: Science, Art, Business

This is a summary of the other STEM disciplines:
 * Science: Experiment, Theory, Math
 * Math: Applications, Beauty, Certainty
 * Technician: Repeat, Intuition, Expertise

Tool Attitudes

 * Technician: Become an Expert using the tool
 * Engineer: Can not major in Shovels, Learn just enough, Use, Hack, Improve, "Those with the most toys win."
 * Scientist: Either Propose experiments (Theorist) or Build tools (experimentalist)

An Engineer's resume does list tools used and tools hacked. But an Engineer is not the collection of tools. Engineering is about changing the world. Communicating successful projects through a resume is difficult. Some companies call engineers "Evangelists" because they are supposed to advocate change.

Scientist Engineer Interaction
Scientists are obsessed with truth, and engineers worry only about what works. Scientists are impractical purists. Scientists make things ragged and messy because things change rapidly. Engineers are pragmatic. It doesn’t matter whether the theory is actually correct in any deep sense. They worry and puzzle until they get something that works. Then they stop, polish, and admire. They don't worry about whether it violates the second law of thermodynamics.

Scientists come up with the experiments and money. Then they work with a team of engineers to design. It actually gets built by engineers and technicians. Normally there is a “project scientist” inside the team who makes sure the engineering group delivers what the scientists wanted. The scientist responsible to granting institution is called a "principal investigator" or PI. Sometimes the PI is the "project scientist".

So does this mean the PI has to stop the engineers from cutting corners? It’s normally the opposite. The scientist gets impatient. It may be the scientist’s toy, but its the engineer’s baby.


 * “Ahh”, say the engineers, “we need to do more tests.”


 * “Oh, and wait a minute, if we open up the cryostat and use a different type of wire the read noise should go down.”


 * “Well,” they say, “it could pass the CDR we suppose; but there is a 5% chance it will fail at altitude. We should really take it apart and re-align. We should change the baffling while we are at it…”

There comes this point in every PI's career where you learn the same lesson that all engineering clients learn. Eventually you have to shoot the engineers and ship the product. The scientist can not be an impractical purist. The PI needs it for their work. Engineers are still basically practical folk. But the lure of the technically sweet, the pride in their work and endless possibilities overcomes their judgement. When asked why, engineers drift into the misty realms of philosophy. The engineer has to be shot.

Most projects involve the creation of innovative software. Talented software engineers love this stuff. The conversations with them are seductive:
 * “oooh, I could make this even better”


 * “Well,” they say, “there is whole new technology emerging.” (OWL, REST, Web 3.0, take your pick)


 * “We should change the whole architecture and re-engineer. In fact,” they say, their eyes glistening, “when you think about it, it makes you realise there’s a whole different approach, I mean for users and for us. It’s difficult to explain.”


 * “but its kinda, well. Hmm. I need to think about this.”

Think??!! You’re not supposed to think! You’re supposed to implement! You’re an engineer!

The trouble with scientists is that they are much more easily seduced into software engineering than hardware engineering. When scientists want hardware, they state what they want and stick to their guns. But with software, the scientist expects to sharpen requirements as the iterative development prototypes emerge. But instead the scientist is seduced and says, “oh, now hang on that gives me an idea. Nah, we got this all wrong, what we want is more like blah. In fact, that's really strange, you know, I read this blog the other day, and it made a very interesting point…”

This is why most software projects fail. Not because the software industry is incompetent or immature in its methodologies. Not because software is just too intrinsically hard. Nope. They fail because this stuff is just too damned interesting with too many ways to do things and too many things to do. Scientists are turned into engineers.