Tuesday, January 22, 2013

Software "Gardener"? No, You're An Engineer!

Every now and then I come across a post which attempts to describe software development as a metaphor. I find most of them to be pretty terrible; they're often trite, and ironically subjective, considering the metaphors describe a field that is constantly trying to define itself objectively.

After a cursory search, I came across Jeff Atwood's post on the exact same subject. He aggregates quite a few of them together, and he even has a favorite. The list goes from the most obvious (science, bridge building and construction), to the most loose comparisons of gardening and artistic endeavors. If you feel it will help you "rally the troops", I guess whatever works is fine. However, why use metaphor when what you do is easily and succinctly described in one word: "engineer".

Yes, believe it or not, you are in fact an engineer. Some people will call themselves a software developer, or a programmer, and that might be an adequate description for most situations, but don't sell yourself short, don't use metaphor, and certainly don't try to convince others they're not an engineer either.

At first, when researching this topic, I was a bit bewildered and slightly amused. But as I kept reading, I was actually a bit insulted. Then recently, it occurred to me that maybe the problem is that the term engineering is generally misunderstood. To be sure, engineering does not imply that you specifically build bridges or construct buildings, any more than it means that you operate a train or locomotive. Engineering is about the application of science and mathematics to solve problems.

Let's look at a definition. The Encyclopedia Britannica references the predecessor of ABET, the Engineers Council for Professional Development in defining engineering as
the creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behaviour under specific operating conditions; all as respects an intended function, economics of operation and safety to life and property...

Ring a few bells? I sure hope so.

As an example (which is not related to buildings or bridges), I graduated university with a degree in Chemical Engineering. My primary courses consisted of a fair amount of science: various physics and chemistry classes, as well as metallurgy and a lot of calculus. However, this was only a foundation in understanding how the material in my engineering courses was derived. My actual engineering courses applied science I learned to phenomena and general problem sets that occur in the field.

Engineers of all disciplines understand that their required tasks will change on a daily basis, but regardless of the task, most are based on the same general set of equations, concepts and processes. Those equations, concepts and processes themselves, are based on decades of science performed in the lab and tested and re-tested in the field. There's absolutely no need for an engineer to re-derive those equations, concepts and processes on a daily basis to do their work. They know the derivations work, have learned the science to understand the path to the derivation, and how to ask the right questions when they hit a corner case not properly explained.

Does THAT ring a few bells? I hope so, but let's assume it doesn't and I'll nail the point home.

Take a moment and think about this, when was the last time you were required to actually calculate "Big-O" for an algorithm? Keep in mind, this is not at all the same as understanding what "Big-O" means, or even being able to calculate it from scratch as practice or for fun. Does that mean you shouldn't know the science or math behind it? Of course not. Being able to understand and select a sort or search algorithm is tremendously important for engineers; developing one that competes at the O(log (n)) is much, much less important in order to solve your assigned problem, and lies squarely in the domain of Computer Scientists.

Personally, I feel like this is one of the reasons why Computer Science education programs are being shut down, and I'm not alone. But that's a topic left for another debate.

When all is said and done, we're engineers. It's not self-aggrandizing, and definitely doesn't need explaining away.

No comments:

Post a Comment