not everything
is captured
by the fitness
function
not everything
is captured
by the fitness
function
Daniel Davis in conversation with CB and LV. Recorded April 1st, 2014
LV: We’ve been reading your blog a lot. We would like to start taking a quote from it. In your article “Patrik Schumacher—Parametricism,” you wrote, “In Intensive Fields Schumacher himself confuses parametricism and parametric, claiming ’the only precursor of parametricism is Frei Otto.’”1 Could you please elaborate on this differentiation? Ultimately, what is parametric design to you?
DD: Schumacher refers to Frei Otto as an example of Parametricism. But the way that Frei Otto designs his architecture is quite distinct from what Schumacher describes as Parametricism. The Parametricism Schumacher is talking about is a stylistic output, but Frei Otto is talking about the material properties that he’s working with and what materials themselves are computing. If I was to distinguish between the two terms, parametric and Parametricism, I think Parametricism is, to me, a style of architecture. Schumacher defines it as a dogma or a heuristic about what is and what isn’t Parametricism. On the other hand, if you look at the term “parametric”, it has a distinct mathematical origin that gives it a very defined use and meaning. Parametric is the thing beside an operation that is causing that interrelationship or link. There is this explicit relationship between the parameter and the outcome. I think what you see happening in Schumacher’s writing is that it’s very easy to get seduced by the outcome and by the image of what is being created.
The stuff that is happening in the background is kind of forgotten. So Parametricism comes to define “parametric,” but we forget where it comes from. From that we have this kind of schism where the two themes – parametric and Parametricism – don’t quite line up.
LV: I don’t really remember from which article, you defined almost in one single word parametric architecture as “a function.”2 Like the most basic mathematical element.
CB: “Quantity is related to parameters through explicit functions.” It’s interesting to note that, also in the same article, you talk about how the early mathematicians who use the term parametric use it as any other technical term. There’s no difference. It’s not a parametric mode of thinking or operating or style.
DD: The word parametric is not a special word in mathematics. It’s just this word, like the word parallel or orthogonal. It’s not a movement in maths, it’s not the next great thing after modernism. It’s only when Schumacher adopts “parametric” that it gets this extra layer of meaning. I think my difficulty with the notion of parametricism comes from this re-appropriation of the word “parametric.” It’s interesting to consider what would happen if Patrik Schumacher had just called it “Hadidism” or something. I probably wouldn’t have a problem with it. It would be this little thing that he was doing. Some people would be really into it, making stuff in that style.
Some people would be like, “yeah, it’s not important.” But I think it’s this idea that Patrik Schumacher is saying that everything we are doing with computers is inherently in his style or inherently leading towards that, which I found problematic.
CB: To go back to the term style for a second, to what degree do you think there is some kind of formal logic or style associated with parametricism or computational design? We see gradients of complex surfaces or undulating modules. How much of that is inherent in the computational tools or techniques? Or is it a result of larger forces?
DD: I think there are two things at play there. One is, I guess, a sort of meme that’s getting generated in architecture, which is that things are emerging within architecture and stylistically people are kind of agreeing and finding this homogeny of what they enjoy. And the other is that computational methods do lend themselves to things which have particular opportunities that are easy to exploit. If you’re making an algorithm, and you want to make a swarm or something, it is relatively easy. You can do that in Processing with a couple of lines of code. Because of that, you can create this complexity really quickly and people get off on that. That’s what it is. But I think it’s important to remember that parametric design isn’t necessarily that. Just because parametric design can be used to do that doesn’t mean that parametric design is that.
For example, we use Revit a lot here at CASE. Revit, at its core, is a parametric software, and people are out there using Revit to build office towers for lawyers that are really fucking boring. And you wouldn’t say that any of that looks parametric. Yet it is computation being used in a parametric way to generate a building.
LV: Sure. Going back to your own definition of parametric architecture, based eminently on mathematics and explicit functions, there are theoreticians like Carpo who are talking about a reemergence of vitalistic and irrational forces in the domain of computational design. He talks, even, about magic, or indeterminacy. How do you see this statement with regard to your definition?
DD: This sort of stuff really fucking pisses me off. [laughter]
DD: There are a lot of people in computational design who are creating problems for themselves that don’t need to be solved. I mean, whether or not we have enough complexity in our lives, who gives a shit? It doesn’t matter. I wouldn’t say architecture’s in a bad position, but it has a lot of inherent problems at the moment. It’s still really expensive to make architecture. Architecture is still a really risky proposition to build. We’re building things that harm the environment. Architecture is still not something that’s accessible to anyone but the rich. These are all, I think, legitimate and valid things to be working on as architects.
Instead, we’re talking about how complex something is or what it looks like. To me they don’t seem like problems that we should be focusing on.
LV: In line with what you said about the swarm—that’s what people go for—there’s a tendency to do complexity for the sake of complexity, just because the tools are giving us the possibility of doing it. But then, another face of computational design, generally speaking, is also optimization. For example, how do you make the best use of the materials for this type of building on this site? Or when you have tons of iterations and you have to select one, so you design a system of evaluation in the end. Is there space for the irrationality that some theorists are talking about? Is there a way to go beyond optimization? Is there a space for “post-optimization”?
DD: I think ideally maybe there is. One of the problems you have with optimization is that not everything is captured by the fitness function. You see this a lot in the work in the 1960s. At that time there was a lot of interest in optimizing floor plates and lots of that work failed. They were trying to work out the optimal walking distance between rooms. The algorithm failed because it couldn’t encapsulate the entire design space. They could find the optimum layout for walking but that wasn’t necessarily important in terms of architecture, or it wasn’t the only important factor in successful architecture. I think maybe in architecture today you see that as well. People will optimize for something and defer the responsibility to the computer or the algorithm.
They’ll say that what they designed is valid because the computer did it, without leaving the possibility that there’s something outside of what they’ve simulated that is itself important. I think there is space for—I don’t know what you’d call it—post-optimization, or I’d call it a more symbiotic relationship between the designer and the computer. The designer is not deferring their authority to the computer, and they’re also not subjugating the computer as being some kind of bad thing.
CB: As we’re talking about deferring responsibility, or even algorithms or computation as capturing the design space, it could be argued that a lot of the people who use a parametric logic or computation in the design process tend to reduce architecture to binaries: right or wrong, true or false. However, as we know the design process is a lot more nonlinear and amorphous than that. Do you think algorithmic or parametric design is able to capture, or be flexible enough to capture, the entirety of the design space? Or to what degree do you think it could do that?
DD: Historically in architecture there’s been this strange resistance to the design process in practice. You’ll see the AIA guidelines for the way that a project is delivered, which works from conceptual design, to design development, to design documentation, and finally to construction. That idea is based on risk mitigation. But there is an opportunity that I see for parametric design, as it applies to the design process.
Because the model is flexible and you can change the parameter, or you can change the way the model itself is structured, so that it’s possible to change the design later in the design process. If we could make the parametric model flexible enough for this kind of change to occur within it, the design process becomes almost inherently more “designer-ly”. The designer could delay design decisions until they can best decide what the impact of those design decisions are. It might then be that an optimization is feeding into that. It might be that their intuition is feeding into that; it might be that they’ve tested out a lot of things in the parametric model. Rather than making that kind of grand gesture at the start of the project, they’re able to make it at the end of the project. Of all the things that we’re discussing tonight, I think that’s probably going to be the most profound change for architecture in the future. And it’s something that isn’t captured when we’re talking about stylistic outputs of architecture. They’re all just really frivolous in comparison to these fundamental changes in how architecture is going to be practiced in the near future.
LV: To follow up on this idea of capturing the entire design process, we are already witnessing a few examples of how computational tools enable the architect to decrease the gap between the conception of a project and the execution of a project. SHoP is a prime example, but then there is also a firm like CASE, trying to decrease the gap between the software developer and the end user.
Somehow, there is a symbiosis, or a blurring of boundaries between previously compartmentalized disciplines. Is it possible for the architect to cover all the various specialties which are currently closed to her or him?
DD: It’s kind of an open question as to where architecture’s going to go with this. One future would be having specialists within architecture firms. There are going to be the people who code, and there will be someone else within the firm who designs, and they’ll work together. The question that I have about that is, if computation is making us more efficient, and if computation is changing the design process in this really profound way, will there be space for anyone who doesn’t know how to do it? And that sounds horribly elitist, and I would say that as someone who knows how to use the computer, “The most valuable skill is using a computer. I’m gonna have a job, and all you guys are fucked!” [laughter]
DD: I don’t know, and no one knows. It’s not even for us to sit here and discuss: it’s going to happen regardless.
LV: We’ve been having many discussions about these divisions, especially in a school like ours, between those “who can code” and those who can’t. We’ve been wondering whether coding is something that we really need to know, not in order to be competitive, but to be able to say something in the future within our own discourse. It seems that not being a specialist, but at least being able to read is vital. It’s a language at the end of the day.
If you don’t know English, then you’re cut out of the market. If you’re not able to speak to computers, it seems to be headed down the same path.
CB: It’s interesting, almost like computational tools and techniques have allowed architects, designers, and many other professionals to capture the knowledge of many other professions and go beyond their traditional boundaries. But the larger industries have not yet caught up with what’s happening. Although software has allowed an expansion of roles across various fields, larger market forces are still compartmentalizing industries and professions. It will be interesting to see how will that play out in ten years’ time.
DD: Another question I have is, is scripting an artifact of software being crap at the moment? Maybe software is going to become much easier to use in twenty years’ time, and you’re not going to have to become a software programmer to use it. You’ll just be a person that uses software.
LV: That’s true, but at the same time, I would argue that if you’re not able to either read or write this kind of language, you will always be depending on someone else that writes for you. Being able to hack digital platforms gives you the freedom to emancipate yourself from the constraints you have been given. In that sense, it seems almost necessary to know how to build your own custom tools. We are currently working on a project that aims to create an open source platform for students to upload their codes and tools where you will be able to hack and build upon someone else’s tool.
Following from this, though, is an increasingly accepted notion that there is an authorless condition of the architect within computational design, because the same project can be hacked or built upon by other people. Do you think that there will be the possibility for architecture to reach such a radical point where the layman or the non-expert will be able to control the process by just moving sliders that someone else has built?
CB: As in Delanda’s essay on algorithmic design, in which he proposes an evolution in the role of the designer, where the designer only sets up a rule set or a process.
DD: I think you have to look at what the designer does in the design process. The job of the designer isn’t so much to come up with a design, but to discover why the design is needed. This whole scenario has already played out in mass customization. You can go on to Nike’s website and get a shoe in any color or design and customize it to your heart’s content. But no one wants to do that, because they don’t know what they want. The job of the designer is to work out what the customer wants. I don’t really see that ever being an option. It’s the paradox of choice, it’s just too much for people to go and design their own place. So, I 100% don’t think that will ever happen.
LV: Do you think the architect as the sole author will always be there?
DD: Yes, definitely. Whether or not they’re called an architect is a different story. It might be that the architect’s authority is eroded by so many other things happening in the building industry, with jobs like designers or project managers. But there is always going to be someone in charge of what has to happen and why.
LV: Given your experience teaching at RMIT, do you see a necessary shift in the way schools of architecture are organized due to the role of computational design? Does this imply a new pedagogy?
DD: This is another question with which I struggle a lot. I’m not sure what we should be doing. One philosophy holds that computation will be a really big thing in the future and that every student who comes in to the school should be taught programming. That’s what happens at RMIT. I was teaching at Melbourne University, and we taught them in 3rd year how to program.
LV: Was it like a core class?
DD: Yes. It comes back to that question, what is programming going to be in the future inside the architecture firm?
It might just be that programming is a skill like rendering. It’s just something that you send off to a dude, and he does it and it comes back to you. In which case, we’ve just trained a whole lot of people for a menial job within an architecture firm. To be honest with you, if I was to say how I thought it should go, I don’t think programming is that important for students to learn in an academic context. I think they should it learn it outside of it. I think the skill of learning to think like a designer, learning how to question and interrogate things, and how to reflect on your own practice are the real core of the education. They are what make architects special and good at what they do. But programming isn’t a defining characteristic, it’s something students can pick up on the side if it interests them.
CB: I read that you’re a fan of Delanda. Thinking about his materialist philosophy and approach, (i.e. the way he discusses the evolution of civilization alongside material process, which he derives from the sciences of dynamics) do you think that you could apply a metric to all phenomena? Another way to put it is, do you think most things can be quantified?
DD: I feel like this is going to trap me in some way… [laughter]Yes, I guess I do. Maybe in my personal philosophy it would be kind of a hard determinism, like the world is pre-ordained in some way. I guess that erodes the idea of some kind of agency within that. I don’t know. Where is this heading?
lity; it is not just that you can think, that you can design…CB: It’s more of a general question. As you know, the offset to this issue is phenomenology, so you could say that they are two opposite ends of the spectrum. And I’m sure a phenomenologist would say, “things cannot be quantified.”
LV: It’s actually interesting, because we’re currently in an experimental studio at GSAPP that works through CATIA. Mark Wigley defines it as in line with what David Benjamin has called “post-parametric,” in the sense that we don’t seek the Schumacher style output. But in order to achieve a desired goal, what inputs do we need in order to achieve that? Most of the time we arrive at a point where we need to understand what is quantifiable and what is not. It seems like that’s when a designer takes a position in the design process and interprets objective and quantifiable data, and says, for example, “For me, this is public space.” There probably aren’t quantifiable sets of data that can say, “Okay, this is public space.” You as a designer interpret it, and for someone else it could be a different range. But for me, it’s in this range.
DD: I feel like that’s a similar problem but not quite related. That’s a problem of what you can quantify practically versus what is quantifiable in a theoretical sense. What we can quantify today isn’t necessarily what is quantifiable in the world.
1 Davis, Daniel. “Patrik Schumacher - Parametricism.” 25 September, 2010. www.danieldavis.com
2 Davis, Daniel. “A History of Parametric.” 6 August, 2013. www.danieldavis.com