Ravi Mohan's Blog

Friday, January 25, 2008

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).


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.


dharh said...

I'll reply here since my reply is already partially made by you.

dharh: "The exception I take to your argument is that Engineering is math. I don't believe the heart of engineering is math. I think it transcends math.

Thus I think software engineering can be engineering regardless of whether it employs math or not. Just as creating algorithms is not necessarily engineering."

Its obvious to me now that the second part is wrong. I didn't think it through enough when I wrote that. However, the rest still stands.

Ravi: "Engineering = mathematics + science + application area"

To finally put my train of thought to rest. Math is a part of engineering, just as models and the manipulation of models and methods (science) are.

Perhaps its the engineer part of me that finds it hard to program without using the tools I know in engineering for programming even if I leave the math part of the modeling behind most times.

In any event your right.

Anonymous said...

I had been an ardent reader of your blog since your magicindian.com. I respect you tremendously, but let me point out that these days your blog entries are vituperative, criticizing the developer community at large. Friend, not everyone can think alike and code perfect. That is the reality.

Thought of jotting a few lines, please don't take it to heart. I still respect you.

Ravi said...

Responding to the anonymous comment above

Ladies and gentle men we have the idiot of the day. Others need to queue up and wait for tomorrow.

Ok onto the comment

"I had been an ardent reader of your blog ... I respect you tremendously,"

On please! Don't read my blog! And don't "respect" me.

Do you think I care two hoots for the "respect" of some anonymous ...ummm.... entity .. on the internet?

"but let me point out that these days your blog entries are vituperative,"

Really? Why don't you point out a blog entry from"these days" where I am "vituperative" (do you even know the meaning of the word?) and quote the sentences in question? You can't ? Thought so!

"criticizing the developer community at large."

What "community" would this be?

The only "community" that would be offended by my saying that most "software engineer" titles are hollow are those who

(a) want to have the "engineer" in the title but
(b) don't want to/can't do any real engineering and
(c) feel all unhinged when someone points out that what they do is not engineering.

Saying that most software developers don't do engineering is not an insult. It is a statement of fact.

And if you know a bunch of "developers" who are insulted you are welcome to this community. The "developer community" I know is nothing like that.

When people speak in the name of collectives it is often because *they* are feeling terrible at seeing their illusions destroyed, not because there is any real "community" out there.

Sorry fella, you need to take a look in the mirror first.

"Friend, not everyone can think alike and code perfect. That is the reality."

And when did I say anything different?

"Thought of jotting a few lines, please don't take it to heart."

Heh heh! You think I "take to heart" what some anonymous idiot on the internet says? You don't know me very well do you? :-)

"I still respect you."

oohhhhh you stiil RESPECT me!! Ohh Thank you thank you thank you!!!!

Wow! And here I was , waiting for my daily quota of "respect" to wake me up.

Go away and do something useful, idiot.

Anonymous said...


That was so funny ...

Pramod said...


Joe Williams said...

Great series.

(You should just ignore the anonymous folk offering gratuitous advice, but then you don't need me to tell you that ;-) ).

Dr Lauffenberger's (spelling?) talk was incredible (and you've paraphrased the first 15 minutes or so beautifully). As a physicist, I wasn't aware of the progress made in Biology. I spent a couple of hours happily browsing the MIT Biological Engineering Department website. There is some incredible research happening there.

Anyway, just a comment to say "Write for yourself". That's what makes this blog interesting. I look forward to the concluding installment.

Binu Jose said...

I'm the person who posted the comment earlier and got a very harsh reply (didnot expect it to be harsh). I have just 2 years of experience after engineering from a college in Kerala and one of my friends mentioned me about your blog.

I barely have 2 years of experience and I have some problem with communication as well and am working on it. Not sure if you rank such people as idiots.

This is my first comment on your blog and received an unexpectedly harsh response. I may be having 1/5th of your years of experience, but am sure I'll graduate from an idiot to respectable developer in the years to come.

Ravi said...


"I barely have 2 years of experience and I have some problem with communication as well and am working on it. Not sure if you rank such people as idiots."

Not at all :-) It isn't about the style of communication or the years of experience backing it up (which is a false metric anyways).t is about the lack of thought that went into it.

1. Don't be "anonymous" if you can help it. *Sometimes* there are reasons for anonymity, but those are rare.

2. When you say things like "you are being vituperative", make sure you have the material to back it up. In other words when you make a claim, support it withe evidence and logic. Quote the sentences that gave you the impression. Don't just proclaim things and expect people to accept what you say just because you say so..

3. Speak for yourself, not some imaginary "community".

4. When you say something, stand behind it. Don't use weasel phrases like "don't take it heart." "I still admire you" etc. One's feelings towards another person or thing are orthogonal to pointing out a flaw in an argument.

The combination of anonymity, unsupported claims, speaking for a non existent "community", and diluting the argument with "admiration" is what I termed idiotic.

Thus for example if you had written something like

"Ravi, you say in blog entry X, statement Y. I don't think this is correct because of reasons A, B, C.
Also In blog entry X, you give no logical reasons or references to support statement Y. In combination with the use of phrases,pm, n Therefore I am led to
believe you are really not making a logical argument, but crafting a piece of rhetoric to insult a particular group. Do I read this correctly?"

THAT would be a reasonable question.

I challenge you again,

show me the "vituperative" entries I made "these days". And who is this "community" that elected you spokesman?

My last few entries, including this one have claimed that what most software "engineer"s do is not engineering. .

I have given examples and logical reasoning in support of every claim I made , including my definition of engineering and a link to the source (Dr Lauffenberger's speech) that I got it from.

If there is an error in the logic, **show me**.


PS: Me thinking one comment of yours is idiotic doesn't make you an idiot. Neither does the number of years of experience . So statements like "2 years of experience" are meaningless.

What makes a piece of written communication worthwhile is the quality and clarity of thought that goes into it.

IceRaptor said...


I wanted to post an personal experience that supports your claim that scientists who don't understand code will be handicapped (in comparison to those that do).

I have a friend attending graduate school in Geology. Most of his classes are fairly traditional - I can't really describe what they are studying (not a geologist!) but there is some mathematics and lots of theory.

The most difficult class for him was one class where the professor involved the students in his research. IIRC, he was analyzing billions of data points that were taken from seismic sensors dredged through one of the oceans.

The professor used python with a C library extension to do the analysis. Essentially what the students were expected to understand was how to interface with the C library in python through a simple python wrapper that minimized the complexity. However, the library was general use and such most of the difficulty was in understanding which (graphing) function to use or what data was 'valid'.

I spent a couple of hours helping him, essentially digesting the Python code. However, we both hit a wall at the implementation section because I don't have a geology background and he wasn't sure which plotting package to use.

Without this program, however, the vast amount of data that they were sifting through - in order to apply their theorems - would be essentially opaque. However, understanding how to graph the data - and how to make that graph appear from the depths of the Python code - was critical to my friend's class.

Fortunately, no one else in the class had Python experience either, so the curve was generous. But I think the above shows an example of what you are talking about.

Ravi said...

@iceraptor (cool name :-D )

"I think the above shows an example of what you are talking about."

Thank You for taking the time to write that up. That was very interesting.

I've had some success introducing Scipy into a research lab (substiting for c++ , which imo , only *really good * programmers should be mucking with).

Prototyping time was reduced by a factor of 10 thanks to SciPy. A smashing success.