Parametric modeling is best known as the technology empowering the nimble geometric feats of many contemporary architects. This new generation of architecture is so reliant upon parametric modeling that designers like Patrik Schumacher, the director of Zaha Hadid Architects, argues that it constitutes “the great new style after modernism.” By his reasoning, and the reasoning of others, parametric modeling is enabling an entirely new type of architecture.

Despite the exuberance, the building industry has been quietly struggling with parametric modeling. In practice, the models are difficult to produce and they often break.

The breakages most commonly occur when the project’s design intention changes. The model will be too inflexible to accommodate the change without the designer either rebuilding the model from scratch or spending significant amounts of time modifying the model. Typically it is easier to just start again.

In the best case an inflexible parametric model will cause an unexpected delay to the project while the model is being rebuilt. In the worst case the designer will be dissuaded from making a change. They will end up with a building that was not so much created with a parametric model as much as it was created for the limitations of a parametric model.

To prevent this situation, the conventional wisdom has been to front-load the project. Make design decisions early to avoid the cost of changing them later on. And if a change has to be made, make it as early as possible since the cost of change only compounds as the project progresses.

Front-loading has an appealing rationale but in practice it fails for two reasons.

The first problem with front-loading is that by forcing design decisions early in the project, the project becomes more resolved and therefore more difficult to change. In effect, avoiding change makes the project even more inflexible.

The second problem with front-loading is that while some changes can be anticipated and even forestalled, many changes come from forces outside the designer’s sphere of influence. No matter how well a project is front-loaded, the client will still change their mind, the market will still change unexpectedly, and designers will change their ambitions as they come to learn more about the project.

Change is inevitable.

The solution therefore isn’t to avoid change but rather to embrace it. Make change an expected and welcome part of the design process. Make parametric models flexible enough that they can accommodate future design intentions.

One way to achieve this is to borrow methods from software engineering.

Parametric models and software essentially work in the same way. There is a set of parameters, a set of formulas, and a set of output values. Changing one of the parameters will cause all of the related outputs to change. In the case of a parametric model, changing the parameter will cause the geometric output to change.

Software engineers face a problem similar to that faced by architects. Software engineers will develop a computer program, which they will then try to change and find the project has become so inflexible that it is often easier to restart the project from scratch.

The exuberance about computers in the 1960s resembled the current exuberance about parametric modeling. Everyone believed that computers were about to change the world but there was a real fear that the then frequent breakages of software would derail the potential of computing.

For the past fifty years software engineers have been developing ways to make the practice of programming more flexible. They have developed algorithms, coding environments, management practices, code structures, and testing processes. With these developments, the breakages that once threatened the industry have slowly abated.

Architects tend to think of parametric models as some sort of analogue to physical modeling. But rather than conceptualizing parametric modeling as another development in the history of design representation, architects are better served by reestablishing their practice in the context of computer programming.

An example of what happens when designers behave like software engineers is evident in the Dermoid pavilion, which was constructed in Copenhagen at the start of 2011.

The Dermoid pavilion is collaboration between architects and researchers from SIAL, Melbourne and CITA, Copenhagen. The brief was a challenging one: construct a doubly curved pavilion from a wooden reciprocal frame. At the project conception the site of the pavilion was unknown, the strength of a wooden frame incalculable, and the circular relationships of the reciprocal frame completely ill suited to parametric modeling. It was a project destined to change.

While parametric models created by architects are typically unstructured, on this project the models were structured into self-contained modules based on principles from software engineering.

With so much of the brief in flux, the project began by exploring how a reciprocal pattern could be distributed across a double curved surface. This progressed into studies looking at the structural properties of the patterns, which developed into investigations of the pavilions details and workflows for producing the shop drawings.

Only towards the end of the project did the overall design of the pavilion begin to emerge. A few days before construction commenced, the team sat down and defined the shape of the pavilion.

Changing the shape of a project days before it’s construction would typically be completely unfeasible. Yet due to the modular structure of the parametric models, it was possible swap pieces of the workflow – even elementary pieces – without disrupting the overall project.

By creating unusually flexible parametric models the Dermoid team was able to effectively reverse the design process. Before they even had a site, they had started with geometric rationalization and structural tests. Once the site was established, only days before construction did they create the napkin sketch of the form.

A project’s form has huge ramifications. Rather than forcing the form to be decided early in order to avoid the difficulty of changing it later, by using a flexible parametric model this decision could be delayed until the project team best understood the implications.

Admittedly this is just one anecdote, but there is strong reason to believe that software engineering offers a proven pathway to overcome many of the challenges the building industry is currently facing when utilizing parametric models. It is only when we come to see the practice of architecture as being something akin to software engineering that we’ll fully realize the potential of parametric modeling.