The Artistic Interpretation of Software
Posted on 22/07/2018
There’s the obvious painting, photography, music and movies; but the definition of art stretches so much further into areas that aren’t just art for art’s sake, walking a line between artistry and functionality. This concept is evident to anyone who looks, cars, interior design, clothing and so much more; all examples of functional art, walking the line between a business model and producing something pleasing to the eye.
I’ve come to realise over the last few years, that software is no different. We balance the time and cost constraints of producing a good application with a look and feel that’s both easy to use and pleasing to look at.
The key difference with the artistry of a software application is how it’s comparable to an iceberg, what you see on the surface is just a small portion of the work that has been put into it. And here lies the problem, who knows what’s lurking beneath the surface.
There are two types of software developers, there are those who are happy to follow instructions, who write code without thought as to the reasons behind it, and then there are those who understand the true artistry of the work, who think things through, who will willingly argue their point when they come across a feature request that just doesn’t fit.
It’s that difference that defines us, it defines what lurks beneath the surface. Any developer can hack together an application, but the dev that sees their work as art truly cares about the entire iceberg. It can sometimes feel like an underappreciated task, a good interface is what provides the majority of positive feedback; but nobody truly sees a good application, it’s hidden in classes, functions and types out of reach from prying eyes. That’s how we define good applications, by what can’t be seen.
The artistic interpretation of software is defined not only by the thoughtfulness put into the user experience, but the planning put into the design process, the structure of internal classes, the cleanliness of code, the use of the simplest approach wherever possible and the friendly arguments that take place until the right approach if found.
I love working with user interface elements, I always have, but it’s something that’s only recently resurfaced in my work. There’s nothing quite like thinking out an interface, watching it take shape, moulding it as you go, seeing an opportunity that isn’t officially listed in the spec and just going in the direction that the artistic element takes you in.
But that’s just what the user sees, the true talent is to continue that approach behind the scenes where it can’t be seen.
I’m lucky enough to work with a bunch of people who feel the same way, the software we produce is our art. I’m also lucky enough to have worked with people who feel the opposite, as with all art, you can only truly appreciate the good when you have the bad to compare to.