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:

1. Is coming up with new and creative solutions to data transformation more of an art or a science?
2. 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! :D