What I learned about programming from Marcel Duchamp
--
I think Marcel Duchamp could have been a great programmer. He loved puzzles, codes, logic, and semiotics; he littered his works with puns and recursions. He ‘retired’ from art (Jay-Z style) to play chess and had a wicked sense of humor. Like lots of developers, he was wily and a smidge lazy, preferring to build clever work-arounds than repeat himself needlessly. Not to say that he couldn’t be dedicated and diligent when faced with a challenging project. His final piece, Étant donnés, took over 20 years to complete.
For those unfamiliar with art history, Marcel Duchamp was a major French-American painter and sculptor (1887–1968). In a handful of works from the 1910’s and 1920’s Duchamp pursued the logical course of abstraction to its’ near limits. He staked out territory that would come to be known as `conceptual art` and set the tone of artistic discourse for the remainder of the 20th century.
In other words, Marcel made art, and he was really good at it.
Before coming to the Flatiron School to study web development, I was a curator working in art museums, galleries, and archives. Duchamp was (and still is) kind of my number one guy. My friends actually make fun of how often I bring him up. (…there’s a Duchamp for that)
You may not be surprised to learn that I think Marcel Duchamp has a lot to say about programming. Or, more accurately, there are several concepts I gleaned from the study of Duchamp that are surprisingly applicable to beginning developers.
Without further ado:
1. Abstraction helps create static views of objects in motion
Complex methods, especially an iterative or enumerative ones, seek to capture a dynamic process in a few clear words. Ruby has some beautifully simple methods like .each or .uniq or my favorite .zip (which weaves together two arrays like a zipper). Each of these methods abstracts a multistep process of literal directions into a simple term that embodies the overall transformation you are hoping to accomplish.
Similarly, Duchamp produced a kind of abstract painting that attempted to capture the multistep process of a figure moving down the stairs. Inspired by the motion picture experiments of Eadweard Muybridge, he reduced the figure to basic shapes of and superimposed successive images of an abstracted human form onto a single canvas. The result, Nude Descending a Staircase, No. 2 (or as the New York Times critic called it “Explosion in a Shingle Factory”), captured the actions in a clear but condensed single form. If he was a Rubyist, perhaps he would have called the painting Nude.stairs.
2. The meaning of an object depends greatly on its context
In 1917, Duchamp began to select mass-produced, commercially available objects and present these objects themselves as art. Fountain (1917) is one of Duchamp’s most famous works and the first of these sculptures, which he called readymades. The original Fountain (now lost) was a standard porcelain urinal, laid flat on its back and signed ‘R. Mutt 1917’ (one of the artist’s many aliases). He wrote the following defense of R. Mutt’s Fountain shortly after it was rejected from an exhibition.
“He CHOSE it. He took an ordinary article of life, placed it so that its useful significance disappeared under the new title and point of view — created a new thought for that object.’ (‘The Richard Mutt Case’, The Blind Man, New York, no.2, May 1917, p.5.)
While centuries of Western thinking had identified art as an original handmade object produced by a skilled creator, Duchamp argued that it was the context — the selection by an artist for display — that made an object art.
All well and good, but what does this have to do with code?
Duchamp’s readymades primed me for an appreciation of variables and scope in Ruby. Variables themselves, like the lowly Fountain, hold no value or meaning if unassigned. The barewords attributed to variables are almost entirely interchangeable. Once assigned a value, a variable holds it’s meaning only so long as it staying within the scope of its naming object. Variables assigned to a method only apply within the body of that method, likewise class variables and instance variables persist only within — you guessed it — the class and the instance in which they were assigned.
I wish I could say that I mastered scope instantaneously, but it took some muddling through for me to be able to spot the limits of variable scope in action. It didn’t help that the same variables kept popping up repeatedly. Everything was called name. Nothing seemed to have an actual name or even refer to an existent entity. Ruby may be ‘object-oriented’ language but this is a language of abstraction not ontology. However, once I began to appreciate the context of each variable scope, I could see through the eyes of Marcel Duchamp. The urinal is Fountain when inside the gallery and then again as a urinal to be discarded outside.
After a few weeks, the mutability of variables and scope now makes intuitive sense to me. Name is just a readymade holding the coded idea as it moves in and out of scope.
2. Build code to be open for extension, not modification. Even your great works are “definitively unfinished”
As we move up the abstraction ladder in Ruby to learn about classes, modules, and other concepts of object-orientation it can seem at first that the programs are being spread awfully thin across a surprisingly large network of relative-requiring files and environments. Perhaps it was naïve to imagine that our programs would be contained to a few methods or files, but I have been surprised at the scale to which the adage of making tiny methods is being applied.
Nevertheless, when I begin to think not just as a single coder in isolation, but as part of a team working together over time to address a multifaceted problem this kind of behavior makes sense. By silo-ing behaviors into single-responsibility chunks of code, I am able to allow the behavior to be extended without modifying the source code. While my brain intuitively wants to still just re-use variables (at this point) rather than substituting methods, this open/closed principle is the kind of respectful strategy that protects both the creator and audience in developing a functional product. Protect your own work by giving clear points of entre to those who will engage with it in the future. And at its heart, this strategy reminds us that we are 1) almost never working in total isolation and that 2) working code is really never ‘done.’
“The creative act is not performed by the artist alone; the spectator brings the work in contact with the external world by deciphering and interpreting its inner qualifications and thus adds his contribution to the creative act.”
I am reminded on both these points of Duchamp’s The Bride Stripped Bare by Her Bachelors, Even (La mariée mise à nu par ses célibataires, même), often called The Large Glass (Le Grand Verre). Over nine feet tall and freestanding, the piece consists of paint, lead foil, fuse wire, and dust applied onto two panes of glass. The Large Glass depicts a frozen moment in two overlapping sequences of erotic-mechanical interactions between the “Bride,” on the upper panel, and her nine “Bachelors” gathered in the lower panel. Many talented scholars have devoted time and energy breaking down the operations within the The Large Glass so rather than butcher their work, I will point you to better sources. Suffice to say, the entire action of the Large Glass is an exercise in iteration, multilayered puns, and literary recursions.
Duchamp labored on The Large Glass from 1915 to 1923. He never reached a completion point, rather called the work “definitively unfinished” and began to exhibit it. During production, he made hundreds of small notes, drawings, and print studies to accompany the main work, each note expanding on the ideas at hand and outlining the actions of each component of the Bride/Bachelor system. These notes read like comments and pseudocode written by an expansive mind who really, really, really could have used some hypertext. Instead they were assembled in 1934 into a limited edition box set known as the Green Box and properly titled The Bride Stripped Bare by Her Bachelors, Even (La mariée mise à nu par ses célibataires, même).
By pairing the painting with the box of ideas, Duchamp fixed the central unfolding action of the The Large Glass — but offered a springboard for interpretation and extension. He recognized that the artist was not alone, that viewers (users) shape a work of art (code). His “definitively unfinished” work foresaw the contributions of other artists (programmers) using the Green Box to build his ideas forward while protecting the original code of The Large Glass.
Btw… The original is now part of the permanent collection at the Philadelphia Museum of Art, but, like his readymades, Duchamp sanctioned the creation of replicas in the 1950’s-1960’s. He was totally open-source.
3. Embrace errors and always have an endgame strategy
The Large Glass was broken during transport in 1926 and carefully repaired by Duchamp. The lines made by the cracked glass delighted him. They were the kind of beautiful haphazard occurance he could have never developed on his own. The lesson here to me is to embrace errors as opportunities for learning. Test-driven development can seem at first to be a slowing thing, forcing you to break down all the specs.
However, our own inclinations can be limiting, especially as beginners, it is easy to stick with a few habitual preferences that may not actually be the best code for the task. As Duchamp stated, “I force myself to contradict myself in order to avoid conforming to my own taste.” Errors — especially contradictory ones — force me to re-examine the detail of the program at hand. Quite often it is a problem of scope or even a typo, but occasionally it points to a large concept I need to more fully understand. Tests force the code to be working before it is fast or beautiful.
After designating the Large Glass as complete, Duchamp retired from art to take up professional chess. He achieved the status of grand master and in 1931 wrote a book on endgame strategy obliquely called Opposition and Sister Squares are Reconciled. The other great reminder here is to start your code with an endgame strategy — always be finishing and always end with working code. Not only do tests and errors force the code to work, they also force it to be complete before you move on. While I often think I get a new concept but, its not until I implement it ALL THE WAY to successful completion that I actually have to demonstrate and test my own understanding.
4. Finally, a few general life tips
Be very serious about your ideas, but don’t take yourself too seriously. At one point, Duchamp sold bonds on himself designed to raise 15,000 francs that he took to gamble at Monte Carlo. The certificate included a picture of him with shaving cream horns.
Finally, don’t be a hater. “What is the use of hating? You’re just using up your energy and die sooner.”
