Monday, January 11, 2010

Software Science vs. Software Engineering

Recently, I am reviewing the title of every team members. I am debating whether I should unify their titles to some favours of “software engineer”: frontend engineer, software engineer, mobile application engineer as suppose to developer.

Does the iron-ring grant you the proper right to use the title "engineer"? Do we have to go as far as certify yourself as Professional Engineer before using that title? Could software scientist ever earned the engineering title? What about software architects? Which government body or professional organization certify software architect “licenses”? How could software professionals be certified / licensed “for the protection of the public health safety and welfare”?

I am a software scientist, well, at least that’s what my degrees said I am. In heart, I am a software engineering evangelist, an technology educator, an infrastructure strategist, an innovator, a motivator, a researcher, a trailblazer, a technology trend setter, …..

When I was young (I still am and always will be, at heart), friends of my elder sister said engineering is difficult; "double E" (electrical engineering) is almost impossible to get into, etc, etc. I was young, stupid, and naïve to believe their BS. I did not realize that difficulty is a relative measure and they are not exactly the smart bunch. I wish I were to know better.

I like the movie “The pursuit of happiness” starred by Will. Smith. My favorite quotes are:


Christopher Gardner: Hey. Don't ever let somebody tell you... You can't do something. Not even me. All right?
Christopher: All right.
Christopher Gardner: You got a dream... You gotta protect it. People can't do somethin' themselves, they wanna tell you you can't do it. If you want somethin', go get it. Period.


Now that I think about it, my sister’s friends said that engineering is difficult because (1) they are in the engineering program and they are on the probation period. (2) they applied for the engineering program but got rejected, and they don’t want anyone else getting into the program to prove that they are inferior. Whatever their reasoning might be, their speech has a profound implication to me back then and now. So, now, you can tell me what I can't do. And I can prove you wrong.

When I apply for university program, because I naïvely believed engineering is difficult, I didn’t apply for any engineering program. I simply applied for the computer science program in a number of universities. I got accepted to all the universities that I applied for, some with scholarship as well. Now that I think of it, if I were to apply for the software engineering program, I would probably get admitted as well. At this point, I still regretted that I did not graduate with an engineering degree. I have done many stupid things in life, but this is one of the most regrettable one. (yea, it's not a big deal ... to you, maybe!)

The silver-lining is that this story reminds me that I should never tell my boy what they can and cannot do. Instead, I need to teach him how to get what you want and the ramification of doing something stupid.

Back to the topic, so what is the difference between software scientist and software engineer? Not by much! What qualify an individual to one title or another? Who knows? Would natural scientist (biologist, chemist, physicist, …) oppose to software scientist calling themselves scientist as computer science is not a natural science? If so what should software professionals call themselves? I have seem a Yahoo! Engineering vice-president called himself “cube-occupant”, but he is just being modest.

So, why do I want to unify my team members to be software engineers instead of software developers? The reason is simple and literal. They are more than merely developing software, they are engineering it. Enough said?

Would my teenage story about not applying engineering program clouding my judgment to wanting everyone to be called software engineers? Definitely, no!

My motivation is clear. I want them to hold a high moral and professionally standard in what they do, to be accountable for their decisions, to understand the ramification of their trade-offs, to master the act of balancing between time and quality, etc. They are, after all, responsible for engineer the software including standardization, backward/future compatibility, regulation compliance, tool licensing, etc, etc.

No comments:

Post a Comment