The Death of the Genius: An alternative history of computation lays bare the problem of invisible labor in architecture



The development of the computer occasioned a radical paradigm shift in numerous fields. According to Matthew Allen (PhD ’19, MArch ’10), however, that was not the case for architecture. In his PhD dissertation, “Prehistory of the Digital: Architecture becomes Programming, 1935–1990,” Allen argues against the dominant narrative that the relationship between computers and architects began in earnest in the 1990s. He asserts instead that computational programming’s essence can be traced to the Bauhaus, and to modernism more broadly. And he claims that its effects—both structural and phenomenological—entered the field at a slow creep. It was subtle enough that some architects today believe they work the same way their predecessors did before the advent of technology, just with different tools.

Allen is a curious pluralist whose excavation of past traditions and, by extension, architectural processes, opens up the possibility of rethinking architecture at its most fundamental level. “We should not be defensive about what an architect is,” he says. “However you want to define ‘architecture,’ whether that’s the creation of environmental effects or the production of the spaces in which we all live, we should look broadly without predetermining it in an unhelpful way.”

In the following conversation about the occluded subculture of computational programming, Allen brings together Paul Klee, Le Corbusier, and the early structuralist dream of the computer in unexpected ways. He also provides a new lens through which to analyze the longstanding problem of invisible labor in the field of architecture.

Invisible labor and not valorizing collective labor enough are big problems in architecture right now. The pervasive, compelling myth still exists that someone called an architect designs a building; he might hire some people to draw it out for him or write up the details, but the idea belongs to this “genius” figure.

Matthew Allenon the dearth of “other figures” in architecture who students can look to as role models.

How does your research problematize the definition of “architecture”?

It’s hard to strike a balance between not taking the accepted definition for granted and giving your new definition immediately. Certainly, the architecture talked about by the computer-using architects was not what would normally be thought of as “architecture.” Design still occurred, but the methods were totally different from standard methods inherited from the Renaissance. The crux of the issue was these architects’ refusal to say that architecture is about how a building looks and that it is instead an activity and also the hidden structure with which designers work—whether that’s a linguistic structure that conveys meaning or a spatial structure that organizes how people use a building.

In what ways does this rethinking of architecture connect to the concept of programming?

“Program” is a 19th-century term for architecture, meaning the activities that happen inside a building. For example, a library has a certain program of having books, reading spaces, etc. While that use of the word is still around, in the mid-20th century the discipline of computer programming developed. But just a little before that, architects became interested in a way of creating architecture connected to this idea of the building’s program that was different from designing by way of drawing a facade and giving form to a building. With this new method, a programmer—who was more of a technician-type figure working in the firm’s back office—would be in charge of organization rather than a “genius” architect. This grew out of a modernist polemic of moving architecture away from fancy-looking buildings into a more technocratic profession of creating functional, cheaper spaces for all of humanity.

Frieder Nake, “Hommage à Paul Klee, 13/9/65 Nr. 2,” (1965)

When does this movement converge with the advent of computer programming?

The change in modernism that you can easily see in abstract art also illustrates the changes occurring in architecture. A good figure to look at is Paul Klee, one of the Bauhaus’s two main artists. In the 1920s, Klee was creating what we would now call generative art, i.e. rather than painting in an expressionistic way, he would set up quasi-rules for himself such as making lines on paper out of which a figure emerged. This was very much the kind of thing you could dispassionately program with a computer. But what Klee and others at the Bauhaus were teaching was a holdover of expressionism that had strong spiritual components; they were by no means trying to fully rationalize this material.

Between the 1920s and the post-war period, many avant-garde figures emigrated from Europe to England. After two world wars, people no longer believed in the utopian ideals associated with modernism, but some still saw potential in modernism’s artistic practices of one kind or another. One group saw themselves as inheritors of the techniques used by Klee and took out what they considered their delusional politics, and wrote algorithms to produce the same kind of paintings. They had politics of their own, though—technocratic politics. They wanted a rational, technocratic designer instead of a delusional “genius” figure. It was this kind of artistic-formalist milieu from which the first computer architecture emerged.

This challenges the dominant narrative that architects “discovered” computers in the 1990s.

The digital architecture that is easily traced back to the 1990s is well within the old-fashioned “genius” mentality of architecture, and it’s convenient for certain architects who want to claim the computer as their own. But this other tradition happening in the immediate post-war period was spread very widely among architects, though generally not the principals of firms. Rather, it spread to architectural technicians—people using computers in the back offices of big corporate firms, or computer consultants who are architects—not people designing fancy buildings. It’s completely continuous from early 20th-century modernism to today, but the thread gets lost in the 1960s, ’70s, and ’80s.

While some may think they’re designing in a 19th-century manner, the way architecture is being created is part of this long series of computational programming changes. It’s just hard to be aware of that.

Francois Molnar, “Simulation d’une serie de divisions de Mondrian a partir de trois elements au hasard,” (1959); and Francois Molnar, “Quatre elements au hasard,” (1959)

The people in those back offices are not often recognized, and certainly not in conversations about architecture by those outside the field.

Invisible labor and not valorizing collective labor enough are big problems in architecture right now. The pervasive, compelling myth still exists that someone called an architect designs a building; he might hire some people to draw it out for him or write up the details, but the idea belongs to this “genius” figure. Yet anyone who has worked in architecture knows a lot happens below that top figure, and maybe most of the design decisions and meat of any project come from below. It’s the same in most professions. But even knowing this, students aren’t given enough awareness of other figures who they can see as role models or alternative methods they can see as valuable. A big part of my work involves building up a whole cast of characters, including back-office computer technicians, and a whole repertoire of techniques that architects can see as their own so that they don’t feel inferior.

There are levels to invisible labor, too. The computer-using architect, for example, still has computer programmers below them who become invisible. One reason this happens is because it’s convenient to package all this invisible labor so that it can be marketed and sold. If you’re a firm like Skidmore, Owings & Merrill (SOM), you can’t show all the messiness of computation; you have to create an image of computation and sell that to clients.

Have you found anything that makes that labor visible?

There are loopholes and short circuits that subvert this structure, when something from a particular lower level asserts itself at a higher one. Look at the iconic Hajj Terminal in Saudi Arabia by SOM (1981). It looks exactly like the screenshot of a sort of output made by form-generating software that an engineer designed in the 1970s. For a historian or theorist, it’s a teachable moment when a charismatic, iconic building expresses something buried deep within the labor hierarchy. And it wasn’t even the sub-consulting engineer himself who revealed this hierarchy but the piece of software he wrote.

This pushes against the notion that the computer is just a tool.

It’s a comforting myth that the computer showed up and architects continued to work the same way they always worked; in fact, a lot of empirical evidence indicates that when computers show up, things change.

The question is, How do you talk about causation? Maybe the most helpful way is discussing what the computer is resonating with and enabling around it. When the computer first arrived on architects’ desks in the mid-20th century, the idea of the computer was much more specific than just a generic tool or drafting table. It was the structuralist device that could shuffle around symbols and create generative art in a tradition of abstraction. It was also very good at creating concrete poetry.

For me, the prototype of the computer for architects was László Moholy-Nagy’s Light-Space Modulator, which is a device that generates environmental effects. Some of the earliest computer-using architects wondered how this kind of effect generation could be systematized and organized. Marshall McLuhan, for example, dreamed of creating a room at the University of Toronto in which any environment from around the world could be recreated with screens, sounds, and smells with a computer.

That was the computer that these architects were dreaming about. It was a very particular device to be used to very particular ends. And it was no surprise that this resonated strongly with postmodernism, which was concerned with the codes buildings embodied and the idea that you could come up with the linguistic code of a building and parametrically recreate it in different forms.

Architects in the 1960s designed computationally, but without computers. Image: Lionel March

Le Corbusier, you argue, in many ways exemplified this slow creep of architecture-becoming-programming. How so?

What connects the two is the particular, structuralist idea in Western philosophy since the 19th century that cultures are made up of codes—that there’s a linguistic underpinning to them. So to understand another culture you would work as an anthropologist to decode the meanings of different things in that culture. This is what Le Corbusier took up. Being a visually oriented person, he saw the vernacular objects in Eastern Europe as speaking the culture. In other words, the culture flows through the person who made it into the object and back out to the people who come into contact with it. The idea was compelling to him because he believed Europe was losing its culture to industrialization, that all these meaningful objects were being replaced by generic ones. Part of his project was to reimbue meaning into the object or make it more artistic. At the end of the day, this cast the architect as someone attuned to these codes. At a place like the Bauhaus, it became a collective computation project.

Just like the functionalist architect, the computer programmer works with a set of codes and creates appropriate outputs without ever creating something new. It’s more about channeling forces through codes into a set of objects that have their own effects. The radical anti-authorial/anti-genius architect stance comes in here, too.

I see Le Corbusier’s purist painting, in which there is a set of industrially created objects which sort of communicate with each other and with the viewer, as exactly what computer scientist Alan Kay argued regarding object-oriented programming and computation works. It’s all about setting up a bunch of objects in communication with each other. That’s all the programmer does, that’s all the architect does, and it’s all the artist does. There’s no creation. It’s juxtaposition. There are no longer authors or “geniuses,” there are only technicians.