An Artist’s Lens on Software Development

I'm a Ruby engineer and a computer musician. In my experience, coding and artistic practice not only inform and complete each other, they are indeed different manifestations of the same essence — creativity.

Ruby is exceptionally well suited for such a reflection, considering the forms of expression it fosters.

One of my goals is to translate my artistic training and ideals onto software engineering, and code quality in particular.

Let's review some of the more and less obvious parallels.

Perception

When I started studying electroacoustic composition, I had to completely relearn how to listen. I spent three years training to separate a source from the sound it produces, decoupling the semantics (meaning) from the aesthetics (quality).

There is an interesting parallel here to coding practice. I learnt the most about how to structure and design code and its interdependencies by reading other people's code — be it by inspecting popular open source codebases, in code reviews, pairing sessions, etc.

And, similar to the distinction between semantics and aesthetics, there's also a difference between a code's functionality (does it work without bugs?) and resilience (will it work when a dozen more developers have touched it to add other features?)

When reading code, thus, it served me well to always consider it from multiple perspectives, such as

• effectiveness (Does it do what it should do? This is mostly covered by tests)
• robustness (How will it fare in the hands of those future dozen developers? Are the affordances to change something attractive enough to stay robust, or will it frazzle?)
• performance (Is it fast? Which tradeoffs need to be made?)
• aesthetics (see below)

Aesthetics

In my eyes, "Code Quality" is a controversial phrase. First, because the common definition of quality is a dichotomy between "good" and "bad", while "quality" can refer to traits or characteristics of an object just the same.

Second, because this is a false dichotomy. It infers that there is "good" and "bad" code, which is really far away from reality. If you skim through the Refactoring book, almost every refactoring leads to a "mirror" smell. It seems to boil down to a matter of preferences, which is really at the heart of the problem.

I contend that the juxtaposition of "beautiful" and "ugly" (or "good" vs. "bad") is a category error — in arts as much as in coding. "Beauty" is always a subjective, highly elusive concept, while aesthetics has a definition, and methods to gauge it, in phenomenology:

Aesthetics is first and foremost tied to the perception (see above) of the individual. And it entails many more perspectives on an artifact than "beauty" (if you think about it, the accepted norm of what is "beautiful" has changed many times over the centuries, and widely differs between cultures). Perhaps the most salient contribution to this discussion stems from Adorno, who in Aesthetic Theory states that "Artworks synthesize ununifiable, nonidentical elements that grind away at each other". And indeed, this does remind us of the elements of an assortment of software modules, called an "application", does it not? Don't they "grind away at each other" and combine to produce novel, unseen, originary results in the form of new functionality?

Aesthetics, one could argue, is a method for contemplating how experiences are composed. And isn't this another synonym for software really, a composition of experiences?

Toy, Mirror, Art — The Three Stages of Technology

I think this is enough as an introduction to coding as artistic practice. We will continue our exploration with a look at how to put this into practice in a later post. I will conclude with a notion concerning media technologies from Paul Levinson that I found most inspiring. He uses an anthropologic approach to divide the use of technology into three stages, using the example of film:

1. Technology as Toy: The first filmmakers weren't artists, but tinkerers, driven not by practical needs or to create something to be consumed, but merely by scientific curiosity.

2. Technology as Mirror of Reality: The next generation of filmmakers still didn't use it to create artworks, but to introspect reality. The famous Horse in Motion shows how film was used to discern the different stages of canter.

3. Technology as Midwife to Art: Only then did the common usage of film transcend from description of reality to creating popular art. Most notably, the medium was now established and people understood its mechanics well enough to be immersed by the experience.

I'd argue, even more with the current developments in AI, computers have only now entered stage 3. They are, quite literally, midwives to art in many respects, thus we should strive to understand more of this characteristic.