Subjectivity in Software

This is second in a series on lessons learned from the art world. The first, about aesthetics can be found here.

Subjectivity matters

Subjectivity is all about what assumptions and preconceptions a viewer brings to the table when evaluating a work. This might make a piece open to interpretation, or it might leave a piece “incomplete” if the viewer doeesn’t have the required background. Take Duchamp’s “Nude Descending a Staircase”

Without the title, one might recognize the stairs and guess at a human form. But this piece’s place in the Cubist art movement confirms that this is a deconstructed object. And although the technique originates here, one’s experience reading comics would make sense of the motion lines, showing the paths that calves and knees move through. Without all of this context, the painting is a muddy, brown mass of shapes.

Subjectivity is unavoidable

Now that we are well into the postmodern art era, it is widely accepted that subjectivity is not only an important aspect of a piece of work, it is unavoidable. If a human is viewing a piece of work, she is filtering it through her own experiences.

While certain aspects of a work can be considered objective, there are always other aspects that are dependent on what the viewer brings. A simple photograph of an apple is inarguably an image of an apple. But why photograph an apple in the first place? Even further, why use a camera and not paint on a canvas? Why show it in a gallery or in a book? Why talk about it as a piece of art in the first place? There is always something missing that a human must fill in.

What about Software?

I find that the tricky part with software is convincing people that humans are part of the audience. The most obvious consumer of source code is the computer itself. However, the moment another person looks at a piece of source code, subjectivity applies.

Why would did the author of this software name this class Foo? Why didn’t he break this into a new file? You might think it overly subtle to think deeply about the choices a software developer makes as he writes, but it all fits into a dialog. New software developers bring a great deal of context with them as they read a codebase. The subjectivity of software lives at that intersection of old and new.

Beside this notion that subjectivity in software is unavoidable, I don’t have much more to add. Perhaps I’m simply justifying the sour look on my face when someone dismisses serious thought into the naming of variables as “just semantics.” It might be a subtle point, but ignoring subjectivity can lead to serious disagreements. Worse, it might lead to someone dismissing a codebase altogether.