Engineering - Some Working Definitions

This is the third in a series of four blog posts. Read parts one and two, to get some context

Dr Douglas Lauffenberger's (from MIT's Biological Engineering Dept) talk (warning - mp3) provided enough ideas for a (sufficient for my purposes) working definition of "engineering".

(paraphrase begins)

Dr Lauffenberger begins by breaking down engineering into two aspects - science ( the study of things that exist ) and technology ( making things that don't exist).

So,

engineering = science (analysis - studying things that exist, break down into components, and methods of combining them) + technology (synthesis, building things by putting together the components identified by analysis ).

Engineering further adds a "design principles" (how things get put together) focus to both analysis and synthesis.

All engineers study mathematics. (This is a given).

An engineering discipline has a base of science for its components and methods of combination. A branch of engineering picks a branch of science to base itself on. So, for example, Mechanical Engineering has a base of Physics and Materials Engineering has a base of Chemistry ( + Physics and the omnipresent Mathematics).

Another way of thinking about engineering is

"measure (properties of systems of interest), (use mathematics to ) model, manipulate (components and methods of combination, guided by the model) and make (things that don't exist)". --> (1)

Yet another way to think about engineering,

Engineering = mathematics + science + application area --> (2)

There can be various combinations of (and subcomponents to) each of these three components.

The "science" component in that equation needs to be manipulatable, quantifiable, modellable etc.

(paraphrase ends)

Later in the speech, Dr L goes into why Biology only recently became modelable etc and so before that, how the various branches of BioEngineering used Physics, Chemistry etc as the underlying science, rather than biology. Biology was often the "application area", but not the underlying science. Thus at MIT biology would be a minor and other engineering disciplines like mechanical or electrical engineering (including comp sci like robotics and algorithms) would be applied to a biological domain like pharmaceuticals or prostheses.

Dr L goes on to explain how this changed and why and how Biology is, these days, a science you can base an engineering discipline on (and you really ought to listen to the full speech), but for the purposes of this post (1) ind (2) are what I am interested in. ie,

engineering = mathematics + science + application area and

(doing) engineering = measure (properties of systems of interest), ( use mathematics to ) model, manipulate (components and methods of combination, guided by the model) and make (things that don't exist).

I suggest that programming fits into the "model" part of things, complementing mathematics. This is just an insight, not rigorously tested etc, but there are a couple of straws in the wind that make me think I am right.

First, a scientist I work with explicitly identified the combination of programming and mathematical skills as a "force multiplier" that enables someone who has mastered both to zoom past someone who is strong only in one, explicitly mentioning a programmer (a genius at programming, way better than I am, who couldn't make as much progress as I could because he couldn't wrap his head around the "maths as a modelling tool" idea) and another person, a scientist this time, who gets stuck periodically because he couldn't write production quality code.

There are analogues in enterprise programming where someone who has mastered a domain *and* programming can provide an order of magnitude more business value (which is the main metric in enterprise programming) than someone who knows only banking or J2EE.

Richard Hamming says in his speech "You and Your Research" (if you haven't read this you really ought to do it right away!)

"... ``How will computers change science?'' For example, I came up with the observation at that time that nine out of ten experiments were done in the lab and one in ten on the computer. I made a remark to the vice presidents one time, that it would be reversed, i.e. nine out of ten experiments would be done on the computer and one in ten in the lab. They knew I was a crazy mathematician and had no sense of reality. I knew they were wrong and they've been proved wrong while I have been proved right. They built laboratories when they didn't need them. I saw that computers were transforming science because I spent a lot of time asking ``What will be the impact of computers on science and how can I change it?'' I asked myself, ``How is it going to change Bell Labs?'' I remarked one time, in the same address, that more than one-half of the people at Bell Labs will be interacting closely with computing machines before I leave. Well, you all have terminals now. I thought hard about where was my field going, where were the opportunities, and what were the important things to do. Let me go there so there is a chance I can do important things. ..."

If that were true in 1986, when Hamming made his speech, how much more true is it likely to be now?

The mistake most scientists make is to consider programming a "blue collar" activity, not worth focusing on (this might be true for the top 1% or so whose native genius will carry them through, but most scientists I know can use all the tools they can get). I hypothesize that in the 21st century a scientist (or engineer) who can't code is handicapped - not so badly as a poor public speaker or a poor writer would be (and both are very vital skills for a research career), but handicapped nonetheless. Maybe there is a case for making (say) SICP + python + algorithm analysis + usage of basic version control tools a part of the science curriculum.

The mistake most programmers (who loathe their cubicle farms and the brain dead enterprise codebases they maintain) make is to think that research and engineering are somehow beyond their ability to tackle. One crucial contributing factor to this perception is that most people learn mathematics as a bunch of formulae to memorize for an exam than as a powerful modeling tool that penetrates and simplifies complex systems. It doesn't help that, in India at least, the engineering and science educational system is fundamentally broken and emphasizes rote learning and obedience to authority over curiosity and intellectual rigor.

I write my blog to help me clarify my thinking. I couldn't care less if no one reads it. (Having said that, I have "met" some brilliant people through the blog). This and the two preceding blog entries came about because I have been struggling with nailing down a research statement - something beyond the current "I am interested in Robotics and Compilers". One of my mentors asked me to do this. I think this is good advice. More on this in the next (and last in this series) post.