In Defense of the Parametricist*

Michael Jeffers 



Fully computer-generated designs may well project a seductive surface appeal but in fact they take place in a world in which the observer has no skin, hands or body. The designer himself remains an outsider in relation to his/her own design and body.

Juhani Pallasmaa1

Scripting in architecture has created innumerable opportunities for unprecedented acts of creativity and design. Computation allows for a fluid and transparent connection between the designer and the process that produces a desired solution to the problem at hand. Because this connection yields a very different process from traditional acts of creation and design, many are hesitant or dismissive of the potential offered by computation. The arguments against the use of scripting take a number of forms: some see it as simply not design; others see the computer, and generative methods, as further separating the designer from the work; and many dismiss it due to its pure novelty, certain in the fact that nothing good can come from something so radical. All of these arguments lack a fundamental understanding of the tool, its uses and misuses.

Scripting is often misunderstood and therefore tragically avoided. It should be understood as a generative device. This device can be infinitely tuned along different potentials, the limits of which are the creativity of the user, technical knowledge of the user, and sometimes the capabilities of the language itself. The generator can be broken down into its components to better explain its relevance to architecture. The fundamental quality of computer code is that it is a set of commands executed by the computer. This differs from out-of-the-box programs in that the architect can literally tell the computer what to do, how to do it, where to store data, and many other things but never why. Kostas Terzidis advocates architects not limit themselves by the sole use of these out-of-the-box programs because it is reduces control over the primary tool.3 If the architect writes the program, then the architect has control of what it does and how it is done.

A script or program is computer code consisting of algorithms. In its simplest form, it is a string of commands and data. Add x to y, return resultant value. Values are needed for the given algorithm to work.4 Variables could be, but are not limited to, data streams, xml feeds, tables of field data, arbitrarily-chosen numbers, lists, arrays, etc. These constitute the parameters. In design these may take the form of a system or rules that the design team establishes. Like any design constraint, the act of selecting parameters impacts and guides a process. To design constraints is a critical and selective act, where an infinite number of possibilities are relinquished. Imagine that the architect says that no columns can intersect a particular space (input). To compensate, the structural system is made to channel the forces out, away and down the sides of the space, resulting in a solution (output). What happened between the input and output? An extrapolation process occurs where the code uses given parameters and the fundamental components of its makeup to solve for variables. This “body” of the program can vary greatly, but, it is, fundamentally, the point where functions are performed. Imagine another scenario: an architect writes a house script – it makes a house. Such a script could be composed in many different ways. One could build all the little pieces of the house into the inputs, essentially placing and mapping all of the shapes and geometries that describe the house, picking points in space, and entering dimensions. Three-dimensional modeling does this, and it is a common solution when working on a computer, but it is also possible to build the cognitive design process into the program. Imagine all the things that make up a house, where they are, how many are there, which side they are on, how each element affects the next, and so on. The architect plugs in location, orientation, number of beds, etc. The code reads it and says, “sun is over here; main living spaces go here; space one needs to be adjacent to space two; this number of beds, therefore this number of bathrooms,” etc. For the sake of clarity, I am imbuing the monologue with a human voice and more information than the computer would typically know to better illustrate the “thought process” behind a script. And it should be noted the architect is responsible for this process. Code is a literal translation of what would otherwise not be written down so explicitly: design intent. In the house script, the location of the main living spaces came before the support space. That was a design decision: the solution produced from code is not invalidated because the architect’s lead-holder was not guided to the paper plane with precision. For both procedures, the justification is the same. The conscious thought process and code, when done well, are congruent. In design we deal with many variables, some which are independent and others that exist within a network of dependencies. The code functions in the same way we do in analyzing and addressing these problems. Priorities are assigned, solutions are found and evaluated, the next piece added, adjustments made, next level, ad infinitum, until the end is reached. This is not to say that it is complete, but rather an iteration has been made, or, in this case, generated.

A script is characterized by inputs, which are determined by the architect, and are inserted into a function written by the architect in order to generate the output. Scripting may be seen as a tool that actively affects its user, exposing its own flaws, and altering the user’s methods. The result is generated; it emerges. It is designed, but through conventional means.

Scripting, parametric modeling, and other digital tools have fundamentally altered the relationship of the architect to architecture. Architecture, as it was once understood, was a meticulous set of decisions made quite literally at every turn. Design was seen as a position where things were subject to the direct intervention of the architect. Lars Spuybroek draws a congruency from the role of the architect to the architecture as a God-universe relationship, where all things are because they are determined to be that way.5 Parametrics allow for a different relationship, but do not destroy the relationship. It operates in a manner similar to biological operations, or life processes, through a complex layering of systems that all actively affect each other and are nested in a matrix of inter-dependencies. The act is not one of divine intervention but a complex set of systems, rules, laws, and protocols.

The new relationship between scripter and outcome, product, ie. “Architecture,” challenges the traditional notion of architect as intuitive author. If all you need is a series of or one panacea script that can take all the multitudes of factors, site data, programmatic needs – empirically measured facts – and plug them in to generate a solution, it may appear that, given the availability of technology today, anyone is capable of doing it. This is not the case. A script must be written by someone who can actively decide how the program interprets, weighs, and calculates the inputs and then how it is put into a given output. Not all scripts will directly lead to architecture, and shortcutting this often leads to misinformed architecture. In this case the architect has misinterpreted what the output of the script was and how it should be used,6 and it could be misinformed as in it was not supplied with enough information to fully solve all of the issues the architecture must address.

If a flocking script maps out density of simulated foot traffic, what about solar needs, wind, materials, structure? This example shows an opportunity for traditional design to take over and interpret a generated output, resulting in a hybridization of analog and digital design methods. Those who criticize the use of parametric processes in architecture are often most skeptical of scripts that can do it all, from site analysis to construction drawings. There is a fundamental misunderstanding here: a script can take raw data and make decisions, decide to ignore, include, assign priority, modify, average, map, etc. These are design decisions. For architects who design without the aid of scripting, design is guided by all of these factors, which are then taken into account with a hierarchy of importance assigning values to each factor, and are interpreted through this lens. Scripting functions in a similar manner, but the process exists in computer code rather than on trace. Scripting is not devoid of design, but a relentlessly precise mapping of design.

Scripting must be seen as a tool, and like all other tools there is a learning curve. In its application to architectural design, it is still relatively new, and the potential for innovation it creates is far from being totally explored and exhausted. 3D modeling faced the same issue in its infancy. In his widely-published work, Embryological House, Greg Lynn manipulated embryonic forms. In calculating all the geometries to achieve an incredibly customized and nearly impossible form, novelty was achieved.7 3D modeling software is now in widespread use; even today, when it remains feasible to design using analog techniques, these tools have become seamlessly tied into the workflow of many practitioners. Scripting will become integrated into practice in a similar fashion. It allows for the design process to be interconnected from start to end. A generated solution can pass through an infinite iterative or recursive loop. Minor alterations to input data can drastically alter the end result. This is not a process of erasure, but of optimization. Just as 3D modeling is not subject to the limited mutability of its analog counterpart, scripting ties all moments in the design process together, so even in late stages of a project, massive changes can be made in minutes.

Skeptics of computation in design rest their arguments in digital methods being fundamentally flawed. The issue of this tool fundamentally lies with the crowd of arguments of the digital being fundamentally bad. Juhani Pallasmaa argues in The Thinking Hand makes his case that the haptic connection is lost when the computer intercedes. This argument overlooks the possibility that generative design will yield a new way of understanding. The architect can understand principles, behaviors, priorities, hierarchies and needs in new ways. The script could be written with these things. The architect could decide to model wind patterns, sun paths, and write in how each of these things would be handled. Then the relationship is reversed. The script solves and shows the architect what would happen if he chose to design in a particular way. If a lead-holder could tell the architect after drawing a window how much glare you would have in an adjacent space in the late afternoon, and could automatically reposition the window iteratively until the lowest amount of glare was achieved while still maintaining the desired view, then it would begin to function like code. The script can, in fact, solve for an optimal balance of these two factors. The script teaches us about our own thought process. It can find the best solution to our problems, and can be the harshest critic of design logic.

It has been expressed, by Patrick Schumaker, among others, that scripting in architectural practice will give rise to a new style: Parametricism. This evaluation is not entirely incorrect. Parametrics and scripting can always be applied in ways that are quite literally decoration and are more about flaunting the new than exploring yet undiscovered applications. It is easy to make things look “parametric,” but in order to be sure we would need a kind of x-ray vision into the code behind the sexy forms that dominate contemporary practice. Often, the scripts would be baseless in their conception. They might explore something like a sine graph and apply that curve modified by some coefficient over some exterior shape. It may very well be that we, users, can derive “delight” from recognizing a curvature is sinusoidal instead of parabolic. But the motives behind those design decisions must be analyzed. The construction industry is simply not poised to accept aesthetic arguments as justification for exploring potentially more expensive and experimental construction methods. And at a fundamental level, scripts are best at crunching numbers, not understanding aesthetic dispositions. Humans do marvel at layered complexity of systems, such as those we see in the natural world. But it seems that the novelty of the tool, and the industry’s lack of experience with it, results in a superficial application and therefore a false assumption that the new tool will yield a new style.

It is my hope that with an understanding of this new tool, its acceptance will become more widespread. I would like to make the argument that scripting, as a tool, is equally as valid as its analog counterparts. The tool is misunderstood and as such is met with fear and rejection. Tools should not be judged by their interface, but by the capabilities they possess!


* Editors’ note: This mysterious character, “the parametricist” refers to those individuals who may be classified as users of parametric tools, individuals who may or may not identify with the dogmatic definitions of “ the parametric style,” “the parametric epoche,” or similar.
1. Juhani Pallasmaa, The Thinking Hand: Existential and Embodied Wisdom in Architecture (Chichester, United Kingdom: John Wiley & Sons, 2009).
2. That is, and should always be, the task of the architect.
3. Kostas Terzidis, Algorithmic Architecture (Oxford: Architectural, 2006), pp. xi-xii.
4. What are x and y?
5. Lars Spuybroek, The Architecture of Continuity: Essays and Conversations (Rotterdam: V2 Pub., 2008), pp. 188-190.
6. The output could be intriguing, and radical, but maybe not a valid solution for the original design problem. Novelty for novelty’s sake.
7.  Greg Lynn, “Greg Lynn: Embryological Houses,” in Contemporary Processes in Architecture, ed. Ali Rahim (London: AD Architectural Design, Wiley & Sons Ltd, 2000), pp. 26-35.