Software Handyman?!?? Not at all. Software Itelf Is Math And There Are Engineers And Scientists
Posted by Bob Warfield on January 23, 2008
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?
kmontgom2003 said
Perhaps software is becoming more “mathy” because we finally have harware which is capable of efficiently supporting “mathy” languages?
Back in the day, when hardware was slow and memory was scarce, we had to resort to languages like C to even be able to do the simplest things on our machines.
Now with multi-Gigabyte, multi-core machines, with compute power and resources to spare, the “mathy” languages can be run
Exercise Science » Software Handyman?!?? Not at all. Software Itelf Is Math And There … said
[…] Here’s another interesting post I read today by smoothspan […]
smoothspan said
It’s true that modern hardware supports “mathier” languages, but even something as prosaic as C is math by my standards. Turing completeness itself is a highly mathematical concept.
Cheers!
BW
Math Resources Blog » Software Handyman?!?? Not at all. Software Itelf Is Math And There … said
[…] Serenity3-0: […]
perpetapaul said
Many of us do apply mathematics to our Software Engineering role. My team and I just used some linear programming techniques to achieve optimization in visit scheduling for distributed field workers. My bacehelor’s degree in Mathematics definitely helped in this case and I apply many concepts every day as I develop software.
Other cases involve understanding how to use the modulus function (one great example is to lightly color the background of every other row in a table), using standard deviation to help the user understand how the data they gathered relates to other projects (BI – business intelligence) and even down to the basic concept of how rounding numbers, then adding those rounded numbers can create rounding errors. Rounding errors is a very important concept if you are working with any type of financial data, including folk’s payroll!
Math is a part of software development for many of us and the title Software Engineer is appropriate.
Paul
waterbreath said
With all due respect…. How long ago did you get this degree?
Very few programming or comp-sci degrees at U.S. schools are still under the purview of the math department. Those that are, are the exception. And I don’t think many would argue with you that, for the graduates of these programs, yes, programming is math.
But these types of degrees are very much in the minority these days.
smoothspan said
Waterbreath, welcome!
It has been a few years, no doubt. But are you saying they don’t teach algorithms any more? Complexity theory? Turing completeness? Nothing about recursion and programming language semantics? Graph theory? Map coloring for register allocation in compiler design?
If they do, it’s okay. Whether its under the auspices of a math department or not, its math. Engineering departments aren’t under those auspices either, but that didn’t stop the original article being published.
If they don’t teach that stuff I guess I just shake my head in wonder, LOL!
Cheers!
BW
rolandhesz said
I remember reading something similar in Rational Edge some… 4 or 5 years ago?
Discipline or Craft, that was the title. It concluded that as it is mostly built on a trial and error basis, not scientific foundations, it is more like a craft.
On the small scale math rules, loops and code snipets are optimized. But the software itself, when you look at it on a higher level (it is a CRM software, it is a Task Manager software), is not really the result of math.
And when you enter the bugfixes (ok, we just fix this here, and I will just put in a new param in the inifile so we can turn it on and off) it turns into real handyman mode.
Of course, with sufficient mathemathics under the hood.
smoothspan said
Roland, there are mathematical proofs now that are so complex that they’re impossible for an individual to understand. They done with the aid of computers. That sure sounds like what you’re trying to say about software when a large program is viewed as a whole.
Thanks for dropping in, I appreciate your insightful comments.
Best,
BW
rolandhesz said
On one hand it’s the complexity.
On the other hand, I am not sure that you can find a mathematical way to prove that your CRM system will help your business, will be easy to use, will be user friendly and will help your customer to work with your company.
What I try to say is that these days software are:
1) Mathematical constructs
2) “Social” constructs
3) Design and usability constructs
and a lot of other things.
smoothspan said
Roland, good points. Not everything is quantitative.
Thanks!
BW