V. The Front and the Back

The front-end/back-end model taken as paradigmatic of digital art by CODEDOC is what is supposed to make the show’s reversal, its focus on the code, make sense. But CODEDOC’s presumptions are several: that digital art is visual; that digital art involves code; and, that its split is binary between a front and a back end. Although these objections might be dismissed as technical or semantic, they are worth reviewing since these presumptions add confusion to a discussion of the art (and since some artists in the show like Brad Paley and Alex Galloway, presented works that attack them).

“Digital Art” is probably not the best term to apply to the kind of work shown in CODEDOC; “Software Art,” although perhaps clumsy and certainly less often used, might be more apt; another likely candidate would be “Generative Art”. “Digital Art” necessarily includes a range of things created, stored and presented using software on a computer or digital appliance, but not necessarily by directly manipulating code. The most common of these are variations of digital images, animations and videos. In defining “Software Art” proper, as a distinct category or subcategory, we might say provisionally that it refers to art that is created by writing code. Digital art more generally, is at some level dependent on software (and hardware), but Software Art is created in the act of coding–by recording in a formal computer language the instructions for executing some set of operations, algorithms.

Generative Art is defined more broadly and might include work not accomplished using computers. Philip Galanter defines it as, “any art practice where the artist creates a process, such as a set of natural language rules, a computer program, a machine, or other procedural invention, which is then set into motion with some degree of autonomy contributing to or resulting in a completed work of art.”[15]

It is impossible not to compare at this point Sol Lewit’s, oft quoted (especially in this context) description of his practice:

"In conceptual art the idea or concept is the most important aspect of the work. When an artist uses a conceptual form of art, it means that all of the planning and decisions are made beforehand and the execution is a perfunctory affair. The idea becomes a machine that makes the art."[16]

Is the same true for software? Is the code the most important part of the work? Is Software Art the code, or is it the code as it is running (what the code does), or both? CODEDOC’s front/back scheme is one way to address this issue by asserting that they are both of a piece. Software does something and it does it in a particular way. The code describes that way; it is a formal description of how hardware should do something. But software is also the doing of it. Each time software is run, it creates an instance of its doing. Each instance, though not necessarily identical, is true to the instructions of its software–the instance is intrinsic in the software and intimately linked with it. Moreover, its variations are not incidental (as might be variations in the execution of Lewit’s instructions, as the result of human factors such as mistakes, or personal differences in style or interpretation) but are in fact encoded by the software which can produce contingent (interactively and environmentally), emergent, and randomized effects programmatically.[17]

An instance of software’s running might be likened to a viewing of a painting, but its running does not always create a visual effect. From our immersion in a multimediated world we are quite used to the idea that software performs for us–for our eyes–and in our presence, but nothing could be further from the truth. Software can and does perform all kinds of tasks, which we never see, or even experience. Some of these may be considered to reside in the realm of art.[18] In any case, an encounter with the art, sensually or intellectually, must occur; and in most cases this will be with what the code does rather than the code itself.

Geoff Cox, et al, in “The Aesthetics of Generative Code” make a case for likening generative art to poetry and assert that “the aesthetic value of the code lies in its execution, not simply its written form. However, to appreciate generative code fully we need to ‘sense’ the code to fully grasp what it is we are experiencing and to build an understanding of the code’s actions.”[19] The authors attempt to balance an emphasis on the code itself and its results. On the one hand code only refers to the programming procedures that lie behind it and on the other hand it extends the intent of its author. Code is in a continual state of becoming, in that the values of its parameters are changed as a result of its execution, creating a multitude of possible outcomes. But neither the intents, the procedures, nor the results, are necessarily obvious from the code, which can be written in such a way that it emphasizes its logical structures or obscures them. For, “Code is intricately crafted, and expressed in multitudinous and idiosyncratic ways.”[20] Since results of the codes execution are not immediately apparent from looking at the code, it is necessary to see the code execute to fully grasp its logic, its possibilities, and its effects.

We expect, as does CODEDOC, that we should be a witness at a front-end.[21] However, intermediary dependencies complicate the notion of a front/back binarism. Except for interpreted languages (such as JavaScript or PERL), computers don’t actually run the code (the source code), they run a compiled version of it, which has been translated into machine language by another piece of software (the compiler). From a certain perspective, it is this executable file that might be naively considered the art object in software art–it is, after all, what one needs (in addition to the appropriate hardware and operating system, of course) in order to experience the program. The source code is in this way separable from the instance of its execution.

One characteristic of software art is that it potentially has a whole range of intermediaries between its creation and the experience of it: authoring > source code > executable > instance of execution > experience. Painting has only: painting > the object > experience. The conventional art object is unitary and whole and requires very little in addition to its presence in order to experience it–its singular presence is also a limit on its experience (it exists as a material object in one place as compared to a digital/linguistic/conceptual object which can be copied exactly and run in an unlimited number of times and places, even simultaneously).

Software is an abstraction that is experienced through its instantiations during runtime or as a result of them. And software always exists as part of a system of dependent relations organized as a continuum of layers of abstract objects that extend through to the user at an interface and down to the binary code on the hardware. This stack may be imagined to have a terminus at the front for the user; but, the stack is a stack of interfaces, and each layer is transmitting and translating from and to contiguous layers, and might just as easily feedback into itself as end. The place of the source code within a circular structure is not usefully determined. An adequate cybernetic description of the software in a system must include the user, the interface, the code and all the rest.

It may be that what is at stake in emphasizing the positionality of the code verses the interface is really human agency. Software problematizes authorial intent in a new way. Putting a human agent back in front of the machine is equivalent to putting this agent in the drivers seat, recuperating symbolically the control that an author (and also the viewer) relinquishes to the code or to the machine. In reading the code for clues to the author’s intention, we repeat this exercise. Code is a message for the machine, not for a human. Code animates the machine. Code is read by the machine operationally, and not culturally (with reference to a social meaning). In J. L. Austin’s terms, code is performative rather than constative (descriptive) language. It is language that executes action. Strangely, Kittler contends that, “There exists no word in any ordinary language which does what it says. No description of a machine sets the machine into motion.”[22] He must mean, that to a degree greater than a pronouncement, for example, of marriage or of knighthood, computer software participates in the control of the world. This world he divides up between hardware, software and wetware, the latter being what is left of the human after the subtraction of hardware. Software then is “that which the wetware makes out of hardware”, a logical abstraction which rules it. Technical innovations like the camera and the phonograph removed the necessity for a human hand to mediate between environment and machine, but this amputation is far less threatening than the mass migration of knowledge and control which makes vulnerable, “the self-definition of European modernity, understanding thought as an attribute of subjectivity.”[23]