Chapter 8 – Discussion: Beyond Toolmaking

Thesis Navigation

• Chapter 8 – Contents
  • 8.0 – Discussion: Beyond Toolmaking
  • 8.1 – Shared Challenges
  • 8.2 – Shared Methods
  • 8.3 – Shared Practices
  • 8.4 – Implications 
• Return to table of contents
• Goto previous chapter
• Goto next chapter
• Download entire thesis as PDF (30mb)

Cite as: Davis, Daniel. 2013. “Modelled on Software Engineering: Flexible Parametric Models in the Practice of Architecture.” PhD dissertation, RMIT University.

8.0 – Discussion: Beyond Toolmaking

Currently “little explicit connection” exists between the practice of parametric modelling and the practice of software engineering, writes Robert Woodbury (2010, 66). In my research I have sought to establish such connections by exploring whether the design of software can inform the design of flexible parametric models. More specifically, I have taken three concepts from the Software Engineering Body of Knowledge 1.0 (Hilburn et al. 1999) and observed, using a reflective practice methodology, their affect when applied to the parametric models of various architecture projects. In the following pages I reflect upon what these case studies contribute to our understanding of parametric modelling and, in particular, our understanding of parametric modelling’s relationship to software engineering. I argue there are connections between software engineering and parametric modelling centred around shared challenges, shared research methods, and shared design practices. These connections position software engineering as an important precedent for architects; a relationship that has implications for how parametric modelling is taught, for how parametric modelling is integrated in practice, and for how we conceive of parametric modelling.

8.1 – Shared Challenges

The challenges with parametric modelling are rarely reported, although they easily experienced. Thomas Fischer (2008, 245) concludes his doctoral thesis by lamenting that firsthand accounts of “failures and dead-ends … seem to be rare and overshadowed by the great number of post-rationalised, outcome-focused reports on digital design toolmaking.” Against this backdrop, one contribution of my research has been to collate the fragmented reports of parametric modelling failures (see chap. 2.3). Sometimes these reports are just a single offhand sentence tucked into a five hundred-page thesis revealing the unnervingly catastrophic behaviour that if the “topology of a project changes the [parametric] model generally needs to be remade” (Gerber 2007, 205). Sometimes these reports come from experts with decades of parametric modelling experience, which inspires them to write tell-all papers about changes breaking models, about a lack of reuse, and about changes having unintended consequences (Smith 2007). These fragmented reports collectively signal that the networks of explicit functions underlying parametric models are vulnerable to being broken by the very thing they are designed to accommodate: change (see chap. 2.3). In many cases the complexity of the parametric relationships leave the designer with only two choices: delay the project and rebuild the model, or avoid the change all together and accept an outcome that was not so much created with a parametric model as much as it was created for a parametric model. This is a challenge often encountered but rarely published.

Software engineers face similar challenges (see chap. 3.1). Like architects creating parametric models, software engineers need to express outcomes in logically precise instructions for the computer. These instructions are susceptible to being broken as the outcomes of the project inevitably change with the project’s development. For a period in the 1960s, scientists feared the breakages would be insurmountable and the limits of computation would not be computer speed but rather the cognition of the programmers creating and maintaining software (Naur and Randell 1968, chap. 7.1). The challenges of 1960s software crisis gave rise to the discipline of software engineering (see chap. 3.1). These are challenges that software engineers have been grappling with for decades, challenges that resemble the fragmented reports of parametric modelling failures.

An important caveat is that creating software is similar, but not identical, to creating architecture. Broadly speaking, parametric models have a very particular user (often the model’s developer or colleague), product (typically the product is the architecture rather than the model), team size (normally just a few people), and project lifetime (often measured in months) (see chapter 3.2 for more details). None of these idiosyncrasies are necessarily abnormal in the context of software engineering, but they are not necessarily common either. This suggests that not all of the challenges faced by software engineers are equally relevant to architects. For instance, architects are likely to have more in common with the challenges faced by a small team of software engineers delivering a project on a tight schedule than they are with the challenges faced by a large team of software engineers developing an operating system to last many years. With this caveat in place, there are many commonalities between the challenges of architects and software engineers.

In some respects the commonalities are unsurprising. A parametric model is, after all, simply a type of algorithm (see chap. 2.1; Dino 2012). Even as far back as 1993, reports were surfacing that parametric modelling was “more similar to programming than to conventional design” (Weisberg 2008, 16.12). Given the known “common ground” (Woodbury 2010, 66) between the two practices, the surprise is that almost no literature connects the struggles of architects with the struggles of software engineers (Woodbury being one exception but even within his writing this connection is only tangentially explained). My research suggests that the challenges architects using parametric models encounter with change are shared to some degree by software engineers, a connection that has implications for how architects may address these challenges.

8.2 – Shared Methods

The flexibility of a parametric model is often framed in a binary of failure and success. My research suggests flexibility is far more nuanced. Parametric models appear to have multiple types of flexibility that are traded off against one another through modelling decisions. To articulate these flexibilities in the case studies I have drawn upon the vocabulary software engineers use to describe qualities of computer code. The case studies show the applicability of quantitative descriptions like lines of code, cyclomatic complexity, construction time, modification time, latency, and dimensionality (see chap. 4.3), as well as Bertrand Meyer’s (1997, chap. 1) qualitative descriptions of correctness, robustness, extendability, reusability, compatibility, efficiency, portability, ease of use, functionality, and timelessness (see chap. 4.4). While these sixteen metrics appear to give a relatively full picture of flexibility, there is certainly scope for further connections between shared methods of appraising software engineering and parametric modelling.

The vocabulary of software metrics helps articulate the differences between various parametric models in my research. By quantitatively measuring 2002 parametric models generated by 575 designers I have been able to show that model size and cyclomatic complexity are strongly correlated, just like they are in software engineering (see chap. 4.3). The survey also established that the average Grasshopper model contains twenty-three nodes, with a high cyclomatic complexity, and virtually no structure (see chap. 4.3 & 6.3). This is first time a large collection of architectural parametric models has been analysed, and it is perhaps the first description of parametric modelling not reliant upon firsthand accounts. In the case studies I was able to combine the quantitative and qualitative metrics to triangulate a more comprehensive understanding of each parametric model’s flexiblity. For example, in the interactive programming case study (chap. 7) it was shown that Yeti’s impact on model latency also had implications for the construction time, functionality, ease of use, and correctness of the model. Being able to describe the flexibility of a parametric model using a vocabulary more nuanced than the current binary of failure and success is a potentially important contribution.

It is important to caution that these measurements are not necessarily predictors of model behaviour. A model may have a low cyclomatic complexity and low latency, be robust and easy to use, but still break with an unanticipated change. Another model, a model that looks to be in far worse condition, may go through the same changes effortlessly. In a similar vein, these metrics are unlikely to measure successfully a project’s progress or quality. Attempts to manage programmers using similar metrics have never been widely successful, which has led one prominent advocate of software engineering metrics, Tom DeMarco, to recently say:

My early metrics book, Controlling Software Projects: Management, Measurement, and Estimation (1982), played a role in the way many budding software engineers quantified work and planned their projects. In my reflective mood, I’m wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no.
Tom DeMarco 2009, 96

This is a significant retraction from a software engineer perhaps best known for coining the adage, “you can’t control what you can’t measure” (DeMarco 1982, 3). Although this adage may not ring true, and although software metrics may not be useful in predicting parametric model behaviour, they are still a valuable vocabulary for researchers describing what a model has done.

In applying these various metrics I have built upon the research methods shared between software engineering and architecture. These methods are already connected to some degree, since software engineers and architects cite common sources like Schön and Cross in their research design. The connection has been further bolstered in recent years by software engineers adopting lean development methods that “sound much like design” (Woodbury 2010, 66), and by attempts to position software engineering (and its associated research) within the field of design (Brooks 2010). While software engineers have shown a willingness to learn from design research, this has largely been an asymmetric exchange. My research has gone against the prevailing by drawing upon software engineering research methods and methodologies to structure research about architecture. While the case studies have shown the potential of this exchange, there remains considerable scope to establish further connections between shared methods of research in software engineering and architecture.

8.3 – Shared Practices

The challenges that change presents for both software engineers and architects have pushed both to improve their practices. The progress of one has been largely unbeknownst to the other, which is perhaps most evocatively illustrated in the parallel curves drawn simultaneously by architect Boyd Paulson (1976) and software engineer Barry Boehm (1976) (see chap. 2.2 & 3.1). Both demonstrate, neither aware of the other, that changes become exponentially more expensive as a project progresses. This cost has seen both architects and software engineers attempt to avoid making changes by employing a practice known as front-loading. In the decades since Paulson first drew his curve, architects have regularly rehashed the curve and its conclusions to justify the practice of front-loading (Patrick MacLeamy is almost always misattributed as the originator, see chap. 2.2). At the same time, in the decades since Boehm first drew his curve, the practice of software engineering has improved to the point where some commentators have suggested cost now approaches a horizontal rather than vertical asymptote. This is a practice that lets software engineers “embrace change” (Beck 1999) rather than avoiding change with front-loading.

The Software Engineering Body of Knowledge Version 1.0 (SWEBOK.1999) (Hilburn et al. 1999) attempts to catalogue the knowledge of a software engineer after three years of practice. In my thesis I have hypothesised that aspects of this body of knowledge are applicable not only to the practice of software engineering but also the to the practice of parametric modelling (see chap. 3.2). In my three case studies I have considered how three aspects of the SWEBOK.1999 – programming paradigms, programming structure, and programming environments – affect the practice of parametric modelling:

• In Case Study A (chapter 5) I considered how programming paradigms impacted the creation of parametric models for the Sagrada Família. I developed a new method of parametric modelling using logic programming and found this to influence the parametric model’s construction time, modification time, latency, and extendability. This case study suggests a model’s programming paradigm is a key control point in tuning the model’s flexibility.
• In Case Study B (chapter 6) I experimented with changing the structure of Dermoid’s parametric models. Despite structure being a fundamental part of software engineering, the overwhelming majority of the 2002 parametric models I surveyed had no structure. The restructuring of Dermoid’s models demonstrated that model structure, rather than model size or cyclomatic complexity, is likely the greatest determinant of model understandability. This has implications for model reuse and project continuity, with structure helping support changes late in the Dermoid project.
• In Case Study C (chapter 7) I applied innovations from software engineering Integrated Development Environments (IDEs) to create a novel interactive programming environment specifically for the challenges of modelling geometry. Across a series of projects this environment reduced the latency of writing code, which has implications for the change blindness (see chap. 2.3) designers sometimes experience when making changes. This case study suggests that the environments architects use to write programs can themselves be sites of innovation.

These case studies each individually contribute a novel method of parametric modelling to the field of architectural design (each has been previously published: Davis et al. 2012; Davis et al. 2011a; Davis et al. 2011b; Davis et al. 2011c). I have been able to prototype these new approaches by building upon numerous developments belonging to what the SWEBOK.1999 classifies as Computing Fundamentals; developments in programming languages, geometric APIs, operating systems, and computer hardware. Even ten years ago there was so little to build upon that creating any sort of parametric modelling environment (like GenerativeComponents) was considered a major achievement. If this trend continues – and at the moment there is no reason to suspect it will not – over time it should become even easier to test and apply new modelling approaches. For example, I rewrote Yeti (the interactive programming environment from chapter 7) to run upon the newly developed pythonOCC and Django frameworks, with HTML5 WebGL as the rendering engine (which was only a few months old at the time). This rewritten version of Yeti runs on any web browser (fig. 78) and suggests a future where developments in Computing Fundamentals empower individuals to rapidly invent novel modelling methods for the peculiarities of a project.

Collectively the three case studies indicate that the software engineering body of knowledge is a fertile ground for improving the practice of parametric modelling. Software engineers have, according to Young and Faulk (2010, 439), spent significant time considering “the essential challenges of complexity and the cost of design” since this is the “primary leverage point” in a discipline where “the costs of materials and fabrication are nil.” The case studies demonstrate that the work software engineers have put into addressing these challenges – challenges partly shared by architects – are often applicable to the practice of parametric modelling. Yet, the case studies only begin to explore the application of this knowledge. Even my work on structuring parametric models (chap. 6) only touches the surface of an extremely rich area of software engineering. Likewise, my research into language paradigms and programming environments presents only one instance of many potential possibilities. Other promising sites for future research (identified in chapter 3.2) include the design, coding, and testing stages of Software Product Engineering as well as Software Management (which is an area of knowledge with many obvious connections to architecture, but one that I have not directly explored in my research).

The software engineering body of knowledge is not the silver bullet to the challenges architects face when working with parametric models. It bears remembering that less than half of all software projects in 2012 were successful (The Standish Group 2012; The Standish Group 2009; Eveleens and Verhoef 2010). What the body of knowledge offers is a precedent for thinking about the practice of parametric modelling. In the case studies these all involved tradeoffs, for example, logic programming (chap. 5) facilitated the un-baking of explicit geometry but also negatively impacted the model’s modification time and ease of use (for a detailed reflection on these tradeoffs see the discussions in chapters 5, 6, & 7). Yet within these tradeoffs are options: options to manipulate the flexibility of the parametric model in ways that did not exist before. Potentially the software engineering body of knowledge and the connections my research reveals between shared challenges, shared research methods, and shared design practices offers a precedent for partly controlling a parametric model’s flexibly – an act that would have significant implications for the practice of architecture.

8.4 – Implications

For Education

The Software Engineering Body of Knowledge Version 1.0 (Hilburn et al. 1999, 20) not only represents what practicing software engineers know, it also represents what software engineers are taught (see chap. 3.2). If the challenges architects and software engineers face are similar, and if the software engineering body of knowledge suggests practices to alleviate these challenges, the question arises: should architects be taught about software engineering when they learn about parametric modelling?

The teaching of parametric modelling has typically been devoid of reference to the practice of software engineering, which is unsurprising given the lack of connection between parametric modelling and software engineering at other levels. Robert Aish (2005, 12) says he aims to get designers to think algorithmically “without demanding that designers become programmers.” Aish (2005, 12) goes on to suggest that designers would benefit from what is almost the antithesis of software engineering: a reduction in the “logical formalism” of parametric models. This ambition comes through in the parametric modelling environments Aish has developed while working at Bentley and Autodesk. When architects learn to use these environments, they are ordinarily taught the “keystroke-by-keystroke instructions to achieve specific tasks” says Robert Woodbury (2010, 8). Consequently, the typical parametric modelling pedagogy follows the practices of teaching non-parametric CAD software much more than it follows the practices of teaching programming and software engineering (see chap. 6.3). Woodbury (2010, 9) argues that the cause (although perhaps it is a consequence) comes from designers being “amateur programmers” and naturally wanting to “leave abstraction, generality and reuse mostly for ‘real programmers’.”

My research suggests that there may be a danger to teaching parametric modelling without the accompanying background of software engineering. With parametric modelling often simplified to keystroke-by-keystroke sequences, it is perhaps unsurprising that even simple software engineering practices, like naming parameters, are not undertaken in 81% of the 2002 models I examined (see chap. 6.3). Regardless of the cause, the consequence is that these unstructured models are demonstrably incomprehensible to other designers. This may be an acceptable situation if designers are, like Woodbury (2010, 9) characterises them, just quickly creating one-off parametric models “for the task at hand.” Yet the reported challenges of making changes to parametric models indicates that many designers are generating and retaining models for more than the immediate task at hand. Designers are developing parametric models that evolve throughout the duration of the project, and designers are frequently using their models to address more than an individual task, often capturing the entire logic of a project within a single parametric model (see chap. 2.3). Each of the case studies in this thesis demonstrates how knowledge of software engineering can help architects through these challenging circumstances. Designers seem ill served by an education that seemingly avoids discussion of these challenges in favour of keystroke-by-keystroke instructions that mimic post-rationally glorified parametric projects. The potential danger in sheltering designers from this knowledge is that rather than making parametric modelling easier, it actually become harder in practice.

How parametric modelling should be taught remains an open question and one deserving of further attention. My research tentatively indicates that designers require some understanding of software engineering to get past the point of making tools that solve isolated tasks. As such, there might be a more nuanced spectrum to the binary Woodbury constructs between amateur and real programmer. Identifying the best way to progress designers along this spectrum is outside the scope of my research, however, I will speculate that the way software engineers are taught may offer another connection to guide the future instruction of designers.

For Practice

Another open question implicated in this research concerns how parametric modelling will impact the practice of architecture. As the practice of software engineering has improved, and as programmers have flattened Boehm’s curve into Beck’s curve (see chap. 3.1), the process of software engineering has radically changed. Boehm’s curve suggested a practice whereby change is avoided through front-loading. Programmers are organised in a rigid hierarchy to push a project through an uncompromising linear sequence of requirements, design, construction, and maintenance (see chap. 3.1). Beck’s curve suggests an alternative practice whereby iterations and continual feedback allow developers to “embrace change” (Beck 1999) even late in the project (Brooks 2010). Small teams of programmers self-organise to spiral through stages of planning, acting, and reflecting. The Standish Group’s industry survey suggests that these agile processes offer “three times the success rate of the traditional waterfall method [a synonym for front-loading] and a much lower percentage of time and cost overruns” (The Standish Group 2012, 25).

The Dermoid case study from chapter 6 signals how similar manipulations of Paulson and MacLeamy’s curve (fig. 79) may impact architectural practice. The Dermoid design process began by exploring both material properties and beam propagation strategies, an exploration that would typically fall into the design development stage of an orthodox design process. The design iterated for over a year, cycling through full-scale prototypes, conceptual parametric models, structural analysis, and design detailing. One of the last decisions to be finalised by the team was the shape of Dermoid, which would ordinarily be a pivotal decision made early in the process (possibly on a napkin). By using parametric models to delay this decision, the design team was able to determine Dermoid’s shape at a point where they best understood how the shape would impact the structure, the site, the budget, the construction schedule, and the experience of inhabiting Dermoid. This is essentially the reverse of Paulson and MacLeamy’s front-loading: rather than making decisions early in order to avoid the expense of changing them later, in Dermoid the cost of change was lowered to the point where critical decisions could be delayed until they were best understood. Robert Woodbury has hypothesised about such changes to the design process, but provides no examples of this occurring in practice:

Parametric modelling introduces a new strategy: deferral… Changing the order in which modelling and design decisions can be made is both a major feature of and deliberate strategy for parametric design. Indeed, a principal financial argument for parametric modelling is its touted ability to support rapid change late in the design process.
Woodbury 2010, 43

The parametric models used in the Sagrada Família’s frontons, in Dermoid, and in the FabPod all demonstrate how parametric models can accommodate late-stage changes. These changes to the fronton’s angle, to Dermoid’s shape, and to the FabPod’s layout would ordinarily be prohibitively time consuming, but the flexibility of the respective parametric models helped lower the cost of change to the point where the changes were welcomed late in the design process. In contemplating how flexibility may impact the practice of software engineering, Kent Beck asked:

What would we do if all that investment paid off? What if all that work [improving flexibility] and whatnot actually got somewhere? What if the cost of change didn’t rise exponentially over time, but rose much more slowly, eventually reaching an asymptote? What if tomorrow’s software engineering professor draws [figure 13] on the board?
Beck 1999, 27

The same questions can be asked of architects. If software engineering techniques enable more flexible parametric models, then perhaps tomorrow’s architecture professors will not be drawing Paulson or MacLeamy’s curve (fig. 79) on the board but rather a curve that resembles figure 80. My research suggests that the consequence of flattening the cost of change extends beyond financial savings and beyond the ability to make late changes. The real consequence may be a more iterative and malleable design practice; a practice where the positioning of design effort is not dictated by the cost of change but rather by the requirements of the project.

Beyond Toolmaking

Edsger Dijkstra, a software engineer I have cited frequently in this thesis, has said of software engineering’s relationship to toolmaking:

Computers are extremely flexible and powerful tools and many feel that their application is changing the face of the earth. I would venture the opinion that as long as we regard them primarily as tools, we might grossly underestimate their significance. Their influence as tools might turn out to be but a ripple on the surface of our culture, whereas I expect them to have a much more profound influence in their capacity of intellectual challenge.
Dijkstra 1970, 7

Architects have long characterised CAD software as a type of tool; whether it is John Walker in 1983 trying to make “AutoCAD become synonymous with ‘drawing tool’” (1983, 1) or whether it is Robert Aish (2011, 23) more recently saying, “software developers do not design buildings. Their role is to design the tools that other creative designers, architects and engineers use to design buildings.” Aish goes on to explain the asymmetric relationship borne of “tools transmitting advantage from the toolmaker to the tool user.” This relationship between maker and user is disrupted by parametric modelling. As Mark Burry (2011, 8) observes, “digital design is now fully assimilated into design practice, and we are moving rapidly from an era of being aspiring expert users to one of being adept digital toolmakers.” He continues, “the tool user (designer) becomes the new toolmaker (software engineer)” (M. Burry 2011, 9 [brackets are Burry’s]). This unification of the user and the maker calls into question the distinction between user and maker that has been inherited from other CAD software. To borrow the words of Edsger Dijkstra (1970, 7), by regarding parametric models primarily as tools, we might [have] grossly underestimated their significance.

The distinction between using and making persists in much of the current discourse regarding parametric models. It persists explicitly in the likes of Roland Hudson’s (2010) PhD thesis, Strategies for Parametric Design in Architecture, when he continually refers to “completed parametric models” almost as if model making cumulates with a definite point of completion from which tool use and designing can begin (see chap. 2.1). It persists when Robert Woodbury (2010, 9) portrays the parametric model as a tool for adequately doing design tasks but never being the design task, saying “the task is foremost, the tool need only be adequate to it” (2010, 9). It persists when Benjamin Aranda and Chris Lasch (2005) write in their book, Tooling, that “the job of designing begins” (2005, 9) only once the tool is made. It persists in architectural education, says John Frazer (2006), because “design computation is still only seen by many as ‘just a tool’ and remote from the real business of creative design, which can be mainly blamed on the dull minds of those who were most part left to teach computing – often as if it were a separate subject.” It persists when Patrik Schumacher (2009a, 15) defines parametricism in terms of stylistic outputs coming from “parametric design tools and scripts.” And it persists when Mark Gage tells architects to “use computation, but stop fucking talking about it” (2011a, 1) and later instructs them to hire software engineers “because these tools are so new to architecture” (2011b, 133). In a less explicit way, the separation between making and use persists in many contemporary definitions of parametric modelling. When authors define parametric as being all of design, or only the designs that change, or design in the style of parametricism, they implicitly focus on what parametric models do (see chap. 2.1). By focusing on the doing, many of these definitions overlook the unique features of a parametric model, such as the presence of explicit relationships linking parameters to outcomes; features that distinguish parametric models from traditional manual tools and from other forms of design representation.

“There is something different, unprecedented, and extraordinary about the computer as it compares to traditional manual tools,” argues Kostas Terzidis (2006, 24). For Terzidis this difference lies in the inability of humans to reason about computational processes such as parametric modelling. He goes on to remark somewhat cattily in an endnote, “architects such as Neil Denari, Greg Lynn, or Peter Eisenman use the term tool to describe computational processes yet none of them has any formal education in computer science” (2006, 34). Indeed, discussions of computer science and software engineering are almost entirely absent from discussions around parametric modelling. Architecture students are generally not taught about software engineering, there is “little explicit connection” (Woodbury 2010, 66) in the academic literature, and many prominent parametric modelling commentators (a number of whom do not themselves use parametric models [M. Burry 2011, 37]) seem more caught up in determining if parametric modelling constitutes a new movement in architecture than they are in acknowledging the real challenges faced by architects using parametric models.

My research has revealed three major connections between parametric modelling and software engineering; connections that link shared challenges, shared research methods, and shared design practices. It is in the shared challenges that the analogy of toolmaking begins to unravel. These challenges are often “overshadowed by the great number of post-rationalised, outcome-focused reports on digital design toolmaking” (Fischer 2008, 245). Yet, in the cracks between the post-rationalised veneer, there are fragments of parametric models that have been shattered by the very thing they were designed to accommodate: change (see chap. 2.3). These catastrophic failures are not from designers quickly creating one-off parametric models “for the task at hand” (Woodbury 2010, 9). Instead, these failures often concern changing the logic of a model that represents an entire project (see chap. 2.3). To borrow a toolmaking analogy, these changes essentially involve turning a tee-square into a french curve while it is being used; a change that is different, unprecedented, and extraordinary compared to any previous drawing tool. Being able to go back and modify a parametric model is a far more distinguishing feature than any outward resemblance to tools in AutoCAD. It is in these modifications that designers are sometimes coming unstuck, but it is also in these modifications that parametric modelling derives its utility and software engineering gains its relevance to the practice of parametric modelling.

This thesis is somewhat unusual in that it chronicles what happens to a range of parametric models throughout a series of projects. These case studies show that design is not something an architect does with a ‘completed parametric model’, but rather something that happens iteratively throughout the parametric modelling process. They suggest a practice whereby the tool user and toolmaker are indistinguishable, and therefore capable of tuning the model’s assorted flexibilities to delay and explore some aspects of the design, while rebuilding sections of the model to accommodate others. There is a gap in our knowledge about how this process happens. While other forms of architectural representation have a rich history of critical enquiry to draw upon, my research indicates that software engineering may offer a similar foundation to the practice of parametric modelling. But doing so requires shifting our focus beyond toolmaking, beyond our infatuation with what parametric models do, and towards what is, for lack of a better term, parametric modelling.

Thesis Navigation

• Return to table of contents
• Goto previous chapter
• Goto next chapter
• Download entire thesis as PDF (30mb)

Bibliography

Illustration Credits

• Figure 78 – Daniel Davis
• Figure 79 – Daniel Davis
• Figure 80 – Daniel Davis