Are Software Developers artists or engineers? This question is asked and answered at least 10 times a month around the bloggosphere. Everyone who is involved with development will have their own view. I have my own, but I haven’t really felt the urge to express it until now. If you find this topic boring, feel free to skip the post and remove me from your RSS feed 
To kick things off I need to try and encapsulate my view of what software actually is. In my view, software, regardless of what it does, has a single job: to transform data from one form to another.
Don’t agree? Give me an example of software that doesn’t ultimately boil down to data transformation and I’ll be happy to try to prove you wrong or retract my summation
It doesn’t make our industry sound particularly glorified, but that’s what we do! We munge, mix-up, transform, transpose and randomise. That’s it! Nothing more, nothing less.
What makes us special is that we’re able to come up with a huge variety of different ways to munge the same set of source data into a (similar) set of results. In our industry there are a million ways to skin the cat. To be good at our jobs as developers, we need to be able to come up with new and efficient ways of doing the same task. We need to be able to create reliable software that describes that process perfectly. We also need to be able to create it fast.
So instead of asking “Are Software Developers artists or engineers?”, we should be asking two questions:
- Is coming up with new and creative solutions to data transformation more of an art or a science?
- Is the production of a set of code that describes how to transform data in a certain way more of an art or a science?
The answer to the first question I think is fairly obvious. It’s definitely a combination of the two. One without the other would produce no output. You need to be able to fully understand the requirements of the software (and hence the set of data transformations) to be able to come up with a way of achieving the desired result. Understanding of the process is not really an art. When you understand the problem, you need to be able to leverage your experience and your creativity to come up with ways of solving that problem. Anyone worth their salt would realise that the first attempt at solving the problem isn’t going to be optimal and really only serves the purpose of clarifying the problem further. If you’re stuck with the problem of a sub-optimal solution, it’s really time to get more creative. Start thinking laterally, and outside the box. In my view, that’s art leveraging off science.
The answer to the second question isn’t pretty simple too. We could get harsh and state that writing code to describe a known-process is pretty much monkey work and doesn’t require much thought at all. Being a developer I’d like to stay away from this view 
There is a bit of an art in producing quality code, and at the same time being aware of the limits, pros and cons of the language you’re using is more on the engineering side.
So the short answer: We’re engineering artists. We’re also arty engineers. We’re also pompous, self-obsessed and opinionated. Ah, that might be just me! 
December 26, 2007
Yup, being pompous is definitely being you! :P
Good points all around though. And couldn’t agree more about what a developer actually does.
December 26, 2007
I had a feeling that someone was going to confirm that for me. Thanks very much mate
*blacklisted* …..
Just kiddin.
I reckon that what I have said does make sense, though I haven’t really quantified the amount that each side of the argument applies to the scenario.
Some people on other forums and blogs have argued that development is all down to engineering or process, and has nothing to do with art - it’s just the developer trying to sound like he has some sort of creative flare. I think the argument is bullshit to be honest. But I am a developer, so I might be biased
December 26, 2007
Let’s take you’re argument at face value. If it is true, then like everything in the world - there are gonna be good and bad artists out there. Some of the stuff you see is gonna be complete pants, and other stuff total genius. But the rub is that in the art world for some Picasso is the genius, while for others it’s Ken Done.
Accounting for taste (in relation to code) would be a very interesting argument to disassemble, in that clearly some code is a cut above the rest, while other code may not look pretty but it does do the job
And I think this is where the engineering side wins out over the artistic side.
Interestingly, I think this is also true at times in the art world. Where I come unstuck is quantifying the greatness of an artwork that doesn’t fit the mold, but still does something for me.
At that juncture… Merry Christmas
December 26, 2007
Nice comment Dan. That’s just made me realise something that I didn’t really clarify in my post - the reason being that I had no idea about until I read your comment!
What is the definition of “art”? Does it encapsulate an end-product? Does it include the “journey” that the artist takes to produce the result?
Your point about art being valued differently depending on the viewer is a good one. To me, art is more about the process (for want of a better term) of creativity rather than the result. I would look at someone’s solution to a problem and see how well it relates to the problem space, analyse the mechanism used to perform the job, and see how well it would match the desired output. In most cases, the desired output can be (fairly) well-defined and hence the “result” isn’t so subjective. The method is really where the creativity lies.
Your point still holds true though, as the solution is still subject the person who’s looking at it. They may or may not like it, and hence they might things it’s crap! Most of the time, developers will look at code that encapsulates a way of doing things and the first thing they’ll ask themselves is: Have I seen this before? If the answer is Yes, then immediately the solution doesn’t seem as “creative”. If the answer is no, the chances of the solution appearing more creative increases. If there are little tricks, or if there is any evidence of thinking outside the box or applying knowledge from a completely different domain that just so happens to work well in the current domain, then again the chances increase.
Of course, the solution might be absolutely friggin’ amazing, but if the code’s bad I’m going to hate it