Sunday, April 10, 2011

Solving the Programming Professional Name Debate

Science is to Computer Science as Hydrodynamics is to Plumbing
unattributed aphorism from the Fortune program which I first saw in the mid 90s.

People who have devoted their lives, or at least their professional lives, to writing computer programs seem to be caught up in a continual debate about how to express what we do for a living.  Everyone seems to have their favorite analogy about what our field actually involves.  Are we best described as engineersdeveloperscraftsmenartistsarchitects? writers? farmers? oysters accreting software pearls? construction workers?1  Frankly, I'm tired of it all.  Like so many other political debates going on right now, the debaters are telling you more about what they want than the reality of the issue.  People who say creating software is an engineering discipline are actually saying they want creating software to be an engineering discipline.  It is high time we stop defining ourselves based on the models for other professions.

Naturally, you will want to know how my method for describing people who write software differs from every other person's.  It's simple.  I'm dropping the analogies.  They clearly don't work.  Computer science isn't science, and software engineering isn't engineering.  That's not to say that we can't take lessons from both science and engineering methods, I certainly do so every day, whether it's isolating variables during debugging like I did back in lab class or doing stress/load testing like a materials engineer.  The lessons are freely available to us without needing to take their roles and titles as well.

If we are to stop defining programmers by what we aren't, we have to examine what we are.  When you sit down to design and implement software, no matter the domain, platform, or language, the basis remains the same: algebra, Boolean logic, and symbolic logic.  All computer programs are nothing more than numbers being manipulated.  All those grand designs, all those layers of abstraction, they are just there to allow us to give context and meaning to those numbers.

Now, maybe you are feeling a frisson of fear.  Deep in your hind-brain the instinct for fight of flight is building up.  You know deep down what I'm about to say, and you really don't want to hear it.  But it's there.  People who write software are... mathematicians.  Wait, don't go!  It's applied math!

Yes, I am being overly dramatic to make the point, but when you sit down and seriously think about it, can you really argue against programmers being first and foremost mathematicians?  But it really starts to become interesting when you think about what being mathematicians implies.  Could changing the titles we use in our jobs away from the ones used now help us as a group?  If the code is all just math, how does that make us look at the different roles within the profession?  Would the attitudes of managers change if they had a department of mathematicians writing software rather than a department of engineers?  What about HR departments and recruiters?  If software is written by mathematicians rather than engineers, what does that say about the need for, or the processes of, designing professional credentials and/or certifications?  Does acknowledging that it's all math allow us to come up with better methods and/or processes for our work?

Defining ourselves by analogy really is a perfectly natural thing for software people to do.  After all, we spend all our days writing programs that model other domains, other jobs, other tasks.  But I really do wonder if there would be a benefit to moving beyond defining programming by comparison to other things.

[1] The last four analogies are from chapter 2 of my favorite book about programming, Code Complete 2 by Steve McConnell.

No comments: