Ravi Mohan says the title “Software Engineer” is wrong because real engineers use mathematics every day.  He goes on to clarify this view slightly by saying, “if I am not using “theory” on a day to day basis, I am not *engineering* anything.”  Modeling is also, apparently a big part of what Mohan thinks Engineers do that Software Engineers do not.  He concludes by saying the title, “should something like ‘Software Maintenance Worker’ or ‘Software Handyman’, but I guess it is easier to hire someone if his job title is ‘Rodent Officer’ instead of ‘Ratcatcher'”.

It would be easy to chalk the article up as a linkbaiting exercise more so than a thoughtful discourse, and it is, but the topic deserves a deeper examination.  The issue of whether Software is science or art comes up a lot, and I’ve written about it myself, so I have some views.

Mohan is a bit vague about whether this applies to all software engineers, or the subset engaged in writing business or enterprise software.  He relies heavily on Raganwald’s discourse here, which is largely focused on business software.  It’s important to review the Raganwald article, No Disrespect, because it offers a decidely different view than Mohan portrays.  Mohan takes the view that Reg argued in the article that programmers are clerks.  He’s missed the subtlety.  Some programmers are clerks just as some engineers in other professions are clerks.  The question Reg poses is whether you want to be a clerk?  If not, then you need to rebel a bit about how your professional situation is treating you and how it operates.  Reg points out that if you’re going to act like a clerk, you’ll be treated as one and shouldn’t complain.  In fact, the article Reg suggests if you want to understand the value of a CS Degree is quite interesting.  In it, Brian Hurt talks about an awful lot of things that sound exactly like what Ravi Mohan says real engineers do.

Mohan’s article made me laugh thinking back on my own Computer Science education.  It was under the auspices of the Math Sciences group at Rice University, and if you think we didn’t do math, you’re mistaken.  When I think about the kinds of math we did, that brings me to my next thought on the subject.  The argument can be made that traditional math is of use to Software Engineers.  Reg starts down that path himself in Raganwald’s response to Mohan.  It’s accurate, but I’ll leave that response to others. 

Here is my, somewhat more radical response:

Software itself is math.

I defy the Ravi Mohan’s to give me a formal definition that shoots that down.  Software is math.  Code is math.  Whether you are from the school that says math is symbol pushing, or the school that says math is giving a notation to intuition, there is a home for you in software.  How could you read something like Godel Escher and Bach and not come away knowing that software is math?  Certainly those that get down and dirty with a detailed understanding of algorithms, programming language semantics, or even lambda calculus (gee, its called a calculus for a reason, no?) must see that this is math.

So I think Mohan is, in the end, tragically wrong in his view that Software Engineers (yes, I am entitled to call them Engineers once again) don’t use math.  In fact, whether you understand software as math is perhaps the defining question of whether you are a Computer Scientist or a Hacker (no pejoratives on the latter).  But this is true in the other Engineering professions too.  Many Engineers are cookbook engineers.  They don’t derive the math.  They don’t create new math.  They just apply the math.  These other disciplines have their cookbook approach.  There is a list of the different kinds of bridges: truss bridges, suspension bridges, yada, yada.  Likewise we have lists of algorithms and design patterns.  Not many engineers ever create a fundamentally new bridge and not many Software Engineers create a new algorithm or design pattern.  So where’s the rub?

Getting back somewhat to the original motivation, which was to slam Enterprise software as being a land of clerks: okay, they have a point.  It can be that way.  The clerks do still use math, but it is mostly arithmetic with a little algebra and no calculus or even trig, metaphorically speaking.  However, it doesn’t have to be that way, and there can be significant competitive advantage when an organization moves away from that point of view.  Ironically, it goes back to the math and “oftware itself is math” issues.  One of the things that separates the Enterprise Clerks from Enterprise Software Engineers is an ability to reach both hands deep into the malleable stuff that is software and mold more exciting architectures.  SOA scratches at the surface, but is a step beyond clerkdom.  I don’t want to get off on a tangent defining how to do exciting Enterprise architecture, but I can tell you it can be done and it is worth doing.

The last point I’ll make is to point out:  isn’t it interesting that many of the newest languages and trends are even “mathier”?  Closures, anyone?