Taking your Job Seriously; the Answer to “Software Engineering”

By Loren Segal on March 24th, 2009 at 11:37 PM

My Ring (tm) Today was supposedly one of the biggest days of my professional life. I took an oath today. An oath to uphold the professional values of the Engineering industry of Canada. Although the Iron Ring ceremony is mostly symbolic and has no affect on my legal status as a professional Engineer (read: I’m not one), it’s generally seen as an essential part of your career. So you would expect that this would be a time of great celebration, a memorable stepping stone to a bright future. The only problem is, I have no short-term intentions of ever becoming an Engineer. Oops?

As I play with my ring, pulling it off, and putting it back on my pinky, I can’t help but wonder if what I’m doing is just a nervous habit or a deep-rooted manifestation of some metaphor that’s highly relevant to what it is I’m writing about. I honestly don’t know. What I do know is how I got here, to this ceremony, to becoming the owner of a special ring some might claim is being wasted on someone who may never “use” it.

Context

If it seems weird to hear someone go through an Engineering program then claim they have no intention of being one, it’s probably important to get context. The program I’m in is called Software Engineering. It’s an extremely young field in Canada, and mostly nonexistent to the south. In Canada, my title is legally recognized and reserved to only those who can call themselves Engineers (like Lawyers and Doctors). However, in the United States there are thousands of Joes, Steves and Johns calling themselves “Software Engineers” with a Bachelor’s of Computer Science or sometimes even no degree at all. It’s therefore not surprising for someone in my position to be having an identity crisis as I’m about to thrust myself upon the job market. There’s a good chance I will have at least one job in my career that’s in the United States (I already had one), which means there’s a good chance I will be working with at least one of those Joe, Steve or Johns. Realistically speaking, going all out and becoming a legally recognized Engineer at this time in my life will have virtually no pragmatic benefit to my career besides some bragging rights. For that reason, I’ve decided to opt-out of the membership role calls for now.

When Chad Fowler came to Montreal to speak at CUSEC 2006, he spoke a lot about software as art versus software as a form of engineering. He took art’s side and of course made very good points, but you couldn’t help that the panel discussion got a little heated; after all, this was the Canadian Undergraduate Software Engineering Conference we were attending. This interaction has since stuck somewhere in the back of my mind and has really driven me to attempt to understand the “engineering versus art” issue in full detail. As a sidenote, I think CUSEC has since stopped putting speakers into situations where they’re forced to debate such foundational issues, maybe not for Chad’s benefit, but some others who came after him.

Software Engineering; the Solution to Buggy Code

Fail Whale + Bridge = Bridge Fail? Let's find out!Software Engineering is a regulated profession in Canada precisely for that reason; so that it can be regulated. The theory is that you don’t see bridges collapsing daily (is infrastructure a bad example to use these days?) because there is more attention paid to safety through liability laws, which is ultimately the product of strict regulation. Similarly, if you treat software the same way you treat these bridges, you could end up with the same software robustness that would make it far less buggy and much more usable to the public, the ultimate goal of the Engineer. Basically speaking, by treating software failures like bridge failures we can place more attention on quality and have a real sense of accountability when it comes to broken software.

Certainly I don’t have to get in all of the negative connotations of the above. I am also not saying Software as an Engineering discipline is useless. There are many areas of software where programmers should be Engineers. Places like Lockheed-Martin, Boeing, Bombardier and NASA. Places where there really is some real “bridge-building” going on. Realistically though, 95% of us aren’t building bridges, just some cheap Web 2.0 apps. Unlike what some cartoons might have you believe, nobody has ever been injured by Twitter’s fail whale.

Most of the time, regulations become restrictive and stifle creativity (you hear that a lot about Wall St. these days). I’m not arguing the cases where such regulation is necessary, but rather the cases where it’s not. This is what has always really bugged me. As someone who will probably never touch NASA code in his lifetime, I’m more interested in the boundary cases of where “Software Engineering” applies. Could the program I spent four years studying ever be useful to my life? Could everything I’ve worked for ever be useful to me as a software developer? Did I just waste my time? As I sat there in the ceremony, it all started to come to me. It was either the culmination of years of thought, or some long overdue realization: it’s really not about “engineering” at all. In fact, it’s all about the ring.

Getting Serious

Just as the ring is symbolic in nature, so was my last sentence. It’s really not about the physical ring, but rather what it means to those hundred odd kids sitting in that auditorium today: they were all serious about this engineering thing. The realization actually took place as I took the oath. It took place as I put on the ring and realized, “I now look different than other software developers”. But am I really that different?

I thought about this for a bit when I got home. I imagined the scenario where I would begin a job at a regular software company as a regular (non-engineer) programmer. Would I be acting differently just because I’m wearing a piece of jewelry that the other developers are not? Would I be more organized, more analytical, more efficient? The answer? Probably not. The truth is, we would (ideally) all care equally about our work. Ideally, we would all be taking our responsibilities to the public seriously. That’s really what engineering is about. You don’t need a ring to take your job seriously, you don’t even need the title “Engineer”, you just need to do it.

I should go back to pointing out that what I’ve just described is a situation relatively unique to the software industry. In other engineering fields, your education brings along knowledge that you really cannot get anywhere else. In Software Engineering, however, we learn a lot of the same things that any B.CS. student would learn. I think the difference is how we were taught to look at these same problems; through a lens of seriousness. Planning our designs with class diagrams, sequence diagrams, interaction diagrams, looking at maintainability through traceability matrices, risk and impact analyses, these are all things that are not only common, but emphasized during my formal training.

Now, by no means do the Software Engineering graduates of Concordia University have a monopoly over taking software seriously, nor are we the only people using UML or analytical tools. I’m sure students from various schools arrive at the same sense of responsibility through different means. The point is that we’ve all made it to that final place, whatever our paths were.

To me, part of this path involves reaffirming my responsibilities by taking an oath and wearing a ring that symbolizes the responsibilities I’ve undertaken as a developer. I’m going to keep wearing this ring, because I really believe in what it symbolizes, not because it makes me feel exclusive. If that’s really what being an Engineer is, then count me in, but I don’t think I should be standing here alone.

An Invitation

I want to invite other software developers to join me as well. I don’t think Engineers should be the only ones taking software seriously. Take an oath of your own, even if it’s purely symbolic like mine, to uphold your duties as a software developer, to make decisions based on value, not FUD, to take your job seriously. Post it in the comments if you’d like. Maybe someone should start a movement with a website or something (takesoftwareseriously.org?).

Questions? Comments? Follow me on Twitter (@lsegal) or email me.