Parametric modelling is hard

Daniel Davis – 13 December 2011

In cracks between the evangelical facade that cocoons parametric modelling with a blanket of positive writing, you catch glimpses of dissent. These are the things you catch people talking about in private between drinks – tall tales of unexpected work, of rebuilding the model, of mistakes and incompetence. As significant as it is, I have never seen anyone write a whole paper on it (unfortunately so much of what is important goes unstated in the rules of publishing). The following six quotes are as close as I have ever got:

  • David Gerber: “When the topology of a project changes the [parametric] model generally needs to be remade…” (2007, 205)
  • Rick Smith “A designer might say I want to move and twist this wall, but you did not foresee that move and there is no parameter to accommodate the change. It then unravels your [parametric model]. Many times you will have to start all over again.” (2007, 2)
  • Jane Burry: “… to edit the relational graph or remodel completely is also commonplace.” (2007, 622)
  • Dominik Holzer et al. “… changes required by the design team were of such a disruptive nature that the parametric model schema could not cope with them.” Part of the model was rebuilt. (2007, 639)
  • Robert Aish and Robert Woodbury: Parametric modelling “may require additional effort, may increase complexity of local design decisions and increases the number of items to which attention must be paid in task completion.” (2005, 151)
  • Mark Burry: If a critical change is made “there is no solution other than to completely disassemble the model and restart at the critical decision.” (1996, 78)


Aish, Robert, and Robert Woodbury. 2005. Multi-level Interaction in Parametric Design. In Lecture Notes in Computer Science, 151-162. Berlin: Springer.

Burry, Jane. 2007. “Mindful Spaces: Computational Geometry and the Conceptual Spaces in which Designers Operate.” International Journal of Architectural Computing, 5 (4): 611-624.

Burry, Mark. 1996. “Parametric Design and the Sagrada Família.” Architectural Research Quarterly, 1 (Summer): 70-80.

Gerber, David. 2007. Parametric practices : Models for design exploration in architecture. Harvard University.

Holzer, Dominik, Richard Hough, and Mark Burry. 2007. “Parametric Design and Structural Optimisation for Early Design Exploration.” International Journal of Architectural Computing 05 (04): 625-644.

Smith, Rick. 2007. Technical Notes from experiences and studies in using Parametric and BIM architectural software. Notes.



Join the mailing list to receive an email whenever a new post comes out. Otherwise, you can follow me on Twitter, or add the RSS feed to your reader.


  • Shaun Farrell 14 December 2011 at 1:10 am

    A great idea for a paper, something to think on and collaborate with the crowd on maybe?

    • Daniel 14 December 2011 at 6:50 pm

      Would be fantastic if someone would write a paper about it, they would save me from spending a chapter of my thesis talking about it….

      I think it would be a difficult paper to write. Saying a parametric model does something you couldn’t otherwise do is fairly falsifiable, but saying a parametric model sometimes becomes stuck is hard to explain conclusively (without referring to yourself as an expert). That is why I suspect most of the quotes are small, offhand snippets, which have slipped through. But if someone knows how and wants to do it, I would be very receptive.

  • Ben 17 December 2011 at 5:13 am

    I’m going to start sounding like a broken record, but directed acyclic graphs are probably not the endgame for parametric design. They are just too rigid. They work very well for an object that maintains topology while changing form or purpose – like an animal or machine – but changes to a design so frequently involve changes to topology that architects spend far more time bulding, rebuilding and maintaining a model than they do using that model to explore a design. It also leads to situations where the model does not quite meet the requirements of the design but is stretched or hacked to meet those needs.

    • Daniel 19 December 2011 at 4:29 pm

      Well keep playing that record because I like how it sounds. In all six of the quotes they are definitely talking about problems with modifying a DAG, whether it is explicitly or implicitly. I guess the next track on that record is always ‘what next’….

      • ipek 12 March 2012 at 6:41 am

        I am currently writing a paper that partially addresses some of the limitations of parametric systems. So it is nice to see others who share the same opinion. i think the rigidity of a parametric model is due to its algorithmic nature. you have to define each and every step of an algorithm precisely, and everything builds upon each other… so editing an algorithm is like the jenga game. when you pull something off, you run the risk of collapsing everything. so algorithmic design is sort of in conflict with design exploration, where you occasionally want to redefine the geometry and the design problem during design.

        about DAG, i think it is only a reflection of the algorithm itself (if we leave aside recursive functions), but it is not the exact source of the problem. the same issues that we face in parametric modeling exist in all other sorts of programming practices, and that’s why software maintenance is such a big industry almost on its own.
        therefore i personally do not see a way out of this as long as the design tool is algorithmic-based.

        • Ben 12 March 2012 at 7:20 am

          This is an interesting debate- putting the fault on algorithms in general is much wider thinking than I had considered. What might be a suitable replacement? Neural nets? Maylines? I still think there are more robust algorithms that can handle a certain amount of noise or uncertainty, such as those dealing with physical analogues (collision detection, springs, etc). It’s pretty bizarre that we are using computational methods with such a rigid heirarchy to produce supposedly continuous, nonheirarchical form…

  • Sivam krish 6 February 2012 at 1:05 pm

    The next track is this :

    ” You can connect some parameters and create a program ” guess what, that is a much cooler thing to do. Because it can do crazy things that parameters themselves cannot do.

    Because those who deal with parameters alone, do not understand or are aware of millions of bytes of code that are written so that parametrisist can push some parameters and be thrilled to bits by what they see.

Leave a comment