Ravi Mohan's Blog

Thursday, January 24, 2008

So what's wrong if you aren't an engineer?

Nothing at all! To quote Reg Brathwaite (again! But the man has a way of using words that is very eloquent. I can't resist).

[This is the second in a series of four blog entries. If you haven't already you might want to read part one first.]

What's wrong with being a clerk? Nothing. It's only a problem if deep in your heart you despise clerks and you spend your life in denial about the career you have chosen. I wouldn't wish that on anyone, so I asked my readers to think about that carefully.

Likewise, we can argue about what activities from programming can or cannot be considered Engineering. But really, even if you don't do any Engineering, what's wrong with that?


My last blog post seems to have ignited a mini firestorm. Observing how people react to an idea is sometimes more fun than the original idea itself. Reg gets it. In one of his replies to a comment (do read his blog entry), he says

"the statement “~p implies ~q” says nothing about whether p implies q." .(typo corrected. Thanks Arne!)

This is a bit more subtle than it seems. Try substituting p = "You use mathematics" and q = "You are an engineer") and try working out "~p => ~q" and " p => q" ( => is implication and ~ is not). You may be surprised !

I am continually astounded at how many people respond to arguments or claims without doing a logical analysis of what's being said. (Note: I am using "argument" and "claim" (and other words like "theory") in the logical/scientific sense, NOT in the " I had this 3 hours argument with my wife. She asked me to wash the car and I refused. At the end I was shouting and she was in tears. My theory is that women are a different species" sense).

When I was a debater, in my younger days, one of the lessons I learned early is to understand that you don't counter an argument from your emotional or "gut" level, by calling your opponent names, or attributing motives to him (unless you are trying to be a politician, when these tactics do pay off).The way to counter an argument is to dissect its logical structure, and show it is invalid (in specific contexts, if required). Rhetoric by itself can be powerful (and many politicians know this), but when layered on top of a logically sound argument is devastating. There are very precise ways of doing this, going back many centuries, at least as far as Aristotle and Plato.

In my last blog post, I made the claim that most software developers are not engineers. Here, I'll make another claim, even more provocative. Most software developers don't understand logic either. You think I am wrong? Quick, (assuming you are a software developer) what is the difference between the "if .. then" construct in programming languages like java and the logical "if ..then" (aka implication, often denoted by =>) ? If you, a software developer, answered correctly without having to think about it, rest assured, you are in a minority.

Using logical implication you can say(assuming we are talking about this Earth and this time stream) "If Napoleon Bonaparte was born in Europe, the Sun rises in the East" and have it evaluate to true. But of course. What's so surprising? "If Napoleon Bonaparte was born in India, the sun rises in the West" or "If Napoleon Bonaparte was born in India, the sun rises in the East" also evaluate to True! :-D. ("If Napoleon Bonaparte was born in Europe, the sun rises in the West" evaluates to False.) What does the birthplace of Napoleon Bonaparte have to do with where the sun rises? ;-)

Confused? heh! Don't worry it is a most people get totally zonked when they see this example for th first time. The key is to realize that implication is not causation. (neither is correlation but that is another topic. See this debunking of a claim that "research supports the effectiveness of TDD" to see an example of correlation vs causation - The trick I pulled is of course that many variants of the English "If.. then" are different from the logical "if ..then". [1]). Many people learn the truth table of implication without really internalizing what it means.

When I teach programmers first order logic, this is a constant stumbling block. The solution is simple. I ask them to think of the logical "if X then Y" (where x and Y are booleans or boolean valued expressions) construct as equivalent to a programmatic "If X then Y else True". The "else True " is key. In other words, (thinking programatically) does X have a value of true? if so return (the truth value of) Y else return true. Apply this to the "Napoleon" arguments and you'll get the correct (logical) answer for all possible combinations.

Why is such a confusing notion important? Proofs are logical structures using the primitives of FOL. A large part of mathematics(and science) is proofs. From science comes engineering. and if you are not using mathematics you are not an engineer (ducks for cover ;-)).

There are 5 connectives (not, and, or, if (or implication) and iff (or double implication) ) and two quantifications (Universal and existential) in First Order Logic, which need to be mastered before one can go on to things like proofs and logical structure. That's the bad news. The good news is that working through a book on logic (and there are PLENTY of those) will teach you how to use logic.

Reg goes on to say (in the same comment stream)

I remind everyone that "exists x such that x ~member of E does not imply that for all x, x ~member of E."

In other words, the fact that not using math means you aren't an Engineer does not imply that using math makes you an Engineer, for whatever definition of math we agree on.

Exactly so!

The point of the last blog post wasn't "you suck you enterprise developer subhuman moron", but "Don't delude yourself". No more, No less. Do what you love. And have fun!

PS: Once you know logic, using to to construct (or deconstruct) an argument is trivial. But for those who want to make sound arguments without necessarily studying "raw" logic (I hope you are not a sw dev ;-)), take a look at "The Craft of Argument" by Joseph Williams and Gregory Colomb.)

[1] Wikipedia

Part Three of this series is here.


Rajat said...

This is great stuff!

I am changing my vote from "monads" to "Proof techniques" for your talk at DevCamp Bangalore.

Anonymous said...

It's funny that you have Raganwald in a post about logic. There are many times where he shows an ignorance of logic in his posts. Most people do.

Arne said...

"the statement “~p implies ~q” says nothing about whether q implies p." .

This is a bit more subtle than it seems. Try substituting p = "You use mathematics" and q = "You are an engineer") and try working out "~p => ~q" and "q => p" ( => is implication and ~ is not). You may be surprised !

Please correct me if I'm mistaken, but to my best knowledge "~p => ~q" is actually logically equivalent to "q => p".
But as far as I understand from the rest of the article this is a typo and what you mean is that it doesn't imply "p => q", which is of course true.

Sofal said...


It's frustrating to see so many people completely miss the point that you're making, including smoothspan, who takes an extremely liberal definition of "math", claiming that "all software is math" and claiming that you are wrong.

I completely agree with what you're saying, and it matches my experience in the field so far, which is why I've decided to go back to school. I'm tired of the trivial clerk-like assignments and the controlled environment that I'm confined to as a "software engineer".

There are too many boring and repetitive jobs out there under the banner of "Software Engineering" or what have you. The title isn't important. What's important is that many of us are getting duped into these dead end code monkey careers after college thinking that they are something more. So many people go along with it that those of us who are serious about what we do end up having to fight hard for a more respectable situation.

Well... fight on I guess.

Ravi said...

Good catch! corrected! Thanks!

This is the kind of snarky comment which I reject. Don't hide behind anonymity make vague generalizations with no evidence.

keep fightinmg indeed.

Gerrit said...

The point of the last blog post wasn't "you suck you enterprise developer subhuman moron", but "Don't delude yourself".

To argue the point, but you are making a value judgment in the second half of the sentence that could be interpreted as construing the first half of the sentence.

Obviously you value mathematics and it's application more highly than 'software integration' - and that implies (in the grammatical sense) a greater valuation of those fields of study.

While I agree with your root statement - that 'engineering' disciplines are defined as the application of mathematics to a frame of reference , I find your refusal to simply state such as an opinion, without caveats, frustrating.

Either you value mathematics and engineering greater than the activities involved in 'enterprise applications', or you don't. If that is true, it follows that 'enterprise applications', and by extension it's practitioners, have less value for you.

Perhaps you are attempting to state that you (as an individual) value 'engineering' to a greater degree while not begrudging any other individual their choice of value.

If that is the case, however, you may wish to avoid phrases like
"Don't delude yourself" which is a command to your reader to evaluate themselves in light of your gauge of value.

As an enterprise 'software integration specialist' who aspires to greater, I agree with some of your points but find the vacillating between stances irritating.

dharh said...

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.

John said...

I'm a Software Handyman from a mid-size firm in St. Louis, Missouri. I've been reading your blog for months, taking solace in knowing there are people out there who love research!
This series of posts really helped spark some real conversation in my office -- it was all good fun!

Ravi said...


"This series of posts really helped spark some real conversation in my office -- it was all good fun!"

That's awesome! "Good Fun" and "sparking conversation" is exactly the response I hoped for!

ering component is staedily increasing

Ravi said...

"Thus I think software engineering can be engineering regardless of whether it employs math or not."

You can think it. That doesn't make it right. Give me a few examples of engineering discipline that don't use math or hard sciences (which in turn depend on math) .

Exclude software dev, Whether software dev is engineering is what the debate is about after all.) .

I've asked you roughly the same question in the comments section of my last blog entry.

*My* stand is, to be considered an engineering discipline, it must be based on a core of mathematics (and hard science).

I can give plenty of examples. Mechanical Engineering is based on Physics (to be more precise Statics and Dynamics) and Material Science for example.

I don't know if you have an engineering degree, but if you did get one without learning maths/science I'd like to know!

You really should read the book I referred to in the last paragraph.

Meanwhile I eagerly await examples of non math/hard science based engineering.

Ravi said...

I've removed my intemperate response to Gerrits's post.

Losing my temper is not something I enjoy!

so ....

This is my modified response,

"please react to what I did say rather than what you think I ought to say. I can't really help it if you feel irritated or frustrated"