Constraints, Creativity, and Programming

Last year, in a post on Goethe and Nietzsche, which invoked the Freedom program (to cure Internet distraction), and which noted the role constraints played in artistic creation, I had referred obliquely to a chapter in my book Decoding Liberation, in which ‘Scott Dexter and I tried to develop a theory of aesthetics for software, a crucial role in which is played by the presence of technical constraints on programmers’ work.’

Today, I’d like to provide a brief excerpt from Chapter 3, ‘Free Software and the Aesthetics of Code’, pp. 90-91:

Understanding how a particularly ingenious piece of code confronts and subsequently masters constraints is crucial to understanding creativity and beauty in programming. Programmers have a deep sense of how their work is made more creative by the presence of the physical constraints of computing devices. Programmers who worked in the early era of computing struggled, in particular, to write code that would work in the tiny memory banks of the time — the onboard mission computer for the Apollo 11 project had a memory of 72 kilobytes, less than that found in today’s least-sophisticated cell phone. This struggle was reflected in the nature of the appreciation programmers accorded each other’s work. Steven Levy’s ethnography of the early programming culture, Hackers, describes the obsession with  “bumming” instructions from code:

A certain esthetic of programming style had emerged. Because of the limited  memory space of the TX-0 (a handicap that extended to all computers of that era), hackers came to deeply appreciate innovative techniques which allowed programs to do complicated tasks with very few instructions. . . . [S]ometimes when you didn’t need speed or space much, and you weren’t thinking about art and beauty, you’d hack together an ugly program, attacking the problem with “brute force” methods. . . . [O]ne could recognize elegant shortcuts to shave off an instruction or two, or, better yet, rethink the whole problem and devise a new algorithm which would save  a whole block of instructions. . . . [B]y approaching the problem from an off-beat angle that no one had thought of before but that in retrospect, made total sense. There was definitely an artistic impulse residing in those who could use this genius from Mars technique (Levy 1994).

These programmers experienced the relaxation of the constraint of system memory, brought on by advances in manufacturing techniques, as a loss of aesthetic pleasure. The relative abundance of storage and processing power has resulted in a new aesthetic category. One of the most damning aesthetic characterizations of software is “bloated,” that is, using many more instructions, and, hence, storage space, than necessary; laments about modern software often take the shape of complaints about its excessive memory consumption (Wirth 1995; Salkever 2003). Huge executables are disparaged as “bloatware,” not least because of the diminished ingenuity they reflect (Levy 1994). Judgments of elegant code reflect this concern with conciseness: “I worked with some great Forth hackers at the time, and it was truly amazing what could be accomplished with what today would be a laughingly tiny memory footprint” (Warsaw 1999).

The peculiar marriage of constraints, functionality, and aesthetic sensibility in source code highlights a parallel between programming and architecture. An awareness of gravity’s constraints is crucial in our aesthetic assessment of a building, as we assess its ability to master the weight of materials, to make different materials cohere. While striving to make the work visually pleasing, the architect is subject to the constraints of the requirements of the structure’s inhabitants, much as the programmer is subject to the constraints of design specifications, user requirements, and computing power.

Artists in other genres struggle similarly: creative artistic action is often a matter of finding local maxima of aesthetic value, subject to certain constraints (Gaut and Livingston 2003). These constraints may be imposed on the artist, as in censorship laws; they may be voluntarily assumed, as when a composer decides to write a piece in sonata form; or they may be invented by the artists themselves, as in Picasso and Braque’s invention of Cubism. Whatever the origin of the constraints, “creative action is governed by them,” and “artistically relevant goals,” such as the facilitation of   communication between artists and the public, are advanced by them (Elster 2000, 212). The connection between creativity and coping with constraints is explicit in programming: “It is possible to be creative in programming, and that deals with far more ill-defined questions, such as minimizing the amount of intermediate data required, or the amount of program storage, or the amount of execution time, and so on” (Mills 1983)….Thus, the act of programming, in its most creative moments, endeavors to meet constraints imposed by nature through the physicality of computation, by the users of the program and their desires for functionality and usability, and by the programming community through the development of shared standards.