Chapter 1 – Introduction

• Chapter 1 – Contents
  • 1.0 – Introduction
  • 1.1 – Problems with Flexibility
  • 1.2 – The Flexibility of Code
  • 1.3 – Aim
  • 1.4 – Methodology
  • 1.5 – Thesis Structure 
• Return to table of contents
• 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.

1.0 – Introduction

Timothy Johnson (fig. 1; Lincoln Laboratory 1964) drags a pen across a flickering screen and, for a brief instance, it looks as though he is drawing. For most people in 1964, this demonstration of Ivan Sutherland’s (1963) Sketchpad will be the first time they have seen someone interact with a computer. Johnson’s actions initially resemble a designer at a drawing board, the ink replaced with light, the impression of the computer’s similarity to the drawing board only broken when Johnson creates a misshapen trapezium (fig. 2) and defiantly states “I shouldn’t be required to draw the exact shape to begin with” (Lincoln Laboratory 1964, 9:00). He then obscures the screen by reaching for a button to his left (fig. 3). When Johnson sits back down he reveals, with a hint of magic, that the trapezium has transformed into a rectangle (fig. 4). The sleight of hand underlying this trick is that when Johnson appears to be drawing he is actually communicating a set of geometric relationships to the computer. These relationships form a specific type of computer program, known today as a parametric model. Changes to the model or to its input variables propagate through explicit functions in the computer to change the model’s output automatically, which allows trapeziums to transform into squares, and allows designers to begin drawing before they know the exact shape.

When Sutherland created Sketchpad, it was optimistic to think designers would gain flexibility by transforming a job a draftsperson did with a sheet of paper into a job a software engineer (Timothy Johnson) did with a computer large enough to require its own roof (the TX-2). Yet, fifty years later, architects sit at computers and increasingly do exactly what Johnson was doing all those years ago. It is a difficult job. I will reveal in this thesis that while parametric models offer the flexibility to accommodate change, there is a tendency for changes to break parametric models unexpectedly. These problems resemble problems software engineers encounter when programming; problems that have led designers as far back as 1993 to declare that parametric modelling is “more similar to programming than to conventional design” (Weisberg 2008, 16.12). Yet despite the shared concerns with accommodating changes, there is currently, according to Robert Woodbury (2010, 66), “little explicit connection” between the practice of parametric modelling and the practice of software engineering. Johnson’s sleight of hand persists. In this thesis I seek to connect these two practices by considering whether parametric models can be made more flexible through the application of knowledge from software engineering.

1.1 – Problems with Flexibility

Design is a journey traced by ever changing representations. “The designer sets off,” Nigel Cross (2006, 8) argues, “to explore, to discover something new, rather than to return with yet another example of the already familiar.” Many others share Cross’s view that design is not simply a leap into a premeditated solution but rather a messy journey necessitated by uncertainty and characterised by iteration (Schön 1983; Lawson 2005; Brown 2009). Key facilitators of this process are external representations, which serve as points of reflection along the way (Schön 1983). Cross (2011, 12) contends that these representations are necessary since “designing, it seems, is difficult to conduct by purely internal mental processes.” Yet representations take time to produce, and they take time to modify. Thus, as change inevitably occurs whist designing, the designer necessarily spends time changing or creating new representations.

From the very beginning, the digitisation of architecture has concerned itself with facilitating changes to design representations. When Sutherland created Sketchpad, he spent considerable time considering how a “change of a [model’s] critical part will automatically result in appropriate changes to related parts” (Sutherland 1963, 22). In today’s lexicon this could be described as parametric, meaning the geometry (the related part) is an explicit function of a set of parameters (the critical part). As Johnson demonstrated, a designer using Sketchpad could change their mind about the relationship between objects (the critical part) and Sketchpad would automatically adapt the objects (the related parts) to satisfy this relationship. For example, a designer might decide that two sides of trapezium should be orthogonal (as Johnson does in figure 2). The designer then modifies the parameter controlling line relationships, and this change filters through the explicit functions in Sketchpad’s parametric engine to trigger the automatic remodelling of the lines so that they meet orthogonally; the trapezium now a square. By making geometric models seemingly easy to change, Sketchpad and the introduction of computer-aided design promised to reduce the hours designers spent manually changing or creating new representations.

It is now almost fifty years after Sketchpad and computers have replaced the drawing boards they once imitated. Many new ways of generating parametric models have been developed: from history-based modellers (CATIA, SolidWorks, and Pro/Engineer), to visual scripts (Grasshopper, GenerativeComponents, and Houdini) and textual programming environments (the scripting interfaces to most CAD programs). The commonality of all these parametric modelling environments is the ability for designers to modify parameters and relationships that trigger the transformation of related model parts. This is now a popular way to create and modify digital models. Fifty years since Sketchpad, Robert Aish and Robert Woodbury (2005, 151) say the hope still remains that parametric modelling will “reduce the time and effort required for change and reuse.”

While it is alluring to think of a design representation flexible enough to reduce time spent remodelling, the reality – a reality commonly not addressed – is that parametric models are often quite brittle. Frequently I find my models have grown so tangled they can no longer accommodate even the most trivial change. Often I just start again. I am not alone in experiencing this: I see my students work themselves into the same situation, I listen to colleagues complain about their models breaking, and I read firsthand accounts from architects detailing the same problem.

When the topology of a project changes the [parametric] model generally needs to be remade.
David Gerber 2007, 205

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.
Rick Smith 2007, 2

To edit the relational graph or remodel completely is also commonplace.
Jane Burry 2007, 622

Changes required by the design team were of such a disruptive nature that the parametric model schema could not cope with them. [They had to rebuild part of the model.]
Dominik Holzer, Richard Hough, and Mark Burry 2007, 639

[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.
Robert Aish and Robert Woodbury 2005, 151

[If a critical change is made] there is no solution other than to completely disassemble the model and restart at the critical decision.
Mark Burry 1996, 78

These authors collectively demonstrate that parametric models used in practice have a propensity for inflexibility, which sometimes leads the model to break (these quotes and their implications are examined further in chapter 2). Often the only way forward is rebuilding the brittle part of the model. In the best case, this causes an unexpected delay to the project. In the worst case, the designer is dissuaded from making the change and ends up with a design that was not so much created in a parametric model as it was created for the limitations of a parametric model. Despite fifty years of refinement and the increased adoption of parametric modelling, inflexible models still cause delays in architectural practice, hinder collaboration, and discourage designers from making changes to their models.

1.2 – The Flexibility of Code

In The Design of Design the Turing award-winning software engineer, Frederick Brooks (2010), frequently cites Schön and Cross as he positions programming as a design discipline. Brooks argues that programming, like other forms of design, is not simply a leap into a premeditated solution but rather a messy journey necessitated by uncertainty and characterised by iteration. During this process software engineers represent ideas with computer code, which primarily contains relationships expressed in a logical syntax. As these networks of relationships develop during the design process, they can become brittle and unexpectedly break. These moments of inflexibility echo moments of inflexibility exhibited by some parametric models. For a period in the 1960s, scientists feared these brittle 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).

Software engineers still struggle with inflexibility. While it is difficult to get precise data, some industry surveys have suggested only 14% to 42% of software projects were successful in 2012 (The Standish Group 2012; The Standish Group 2009; Eveleens and Verhoef 2010). In a discipline where the “costs of materials and fabrication are nil,” Young and Faulk (2010, 439) argue that the primary determinants of a programmer’s success become “the essential challenges of complexity and the cost of design.” Accordingly, the Software Engineering Body of Knowledge Version 1.0 (Hilburn et al. 1999) – which categorises the expected knowledge of a programmer – is filled with management strategies, algorithms and data structures, problem decomposition tactics, programming paradigms, and coding interfaces to reduce both the complexity and the cost of design. This is the cumulative wisdom from years of struggles with inflexibility and these are the issues programmers talk about.

In contrast, architects are told by Mark Gage (2011, 1), the assistant dean at the Yale School of Architecture, to “use computation, but stop fucking talking about it.” Gage (2011, 1) goes on to parody the way architects talk, justifying computational projects as coming from “secret code found in the lost book of the Bible handed to [them by their] Merovingian great grandmother” (2011, 1) or deriving from “a semester producing the most intricate parametric network ever seen by man” (2011, 1). While there is obviously an element of truth to Gage’s polemic caricature, it does not necessarily support his conclusion that architects should stop talking about computation. Robert Woodbury (2010, 66) has pointed out, “parametric modelers do have common cause with professional programmers” but “there is little explicit connection between them.” From this point of view, the problem is not so much that architects are talking about computation, but rather that architects are typically talking about computation in fairly extraneous terms compared to the exchanges characteristic of software engineers.

In this thesis I explore whether the debates surrounding the design of software are applicable to the design of flexible parametric models. I position change as an essential, desirable, and unavoidable aspect of both software design and parametric design – a quality both disciplines stiffly embrace in their practice. The relationship between the two disciplines is traversed in my research through three case studies, which take methods inspired from software engineering and apply them to the creation of parametric models. These three case studies map a new territory for architects; territory that concerns the way parametric models themselves are structured and considers what architects can learn from software engineers to improve the flexibility of their parametric models in the face of change.

1.3 – Aim

The aim of this research is to explore whether the design of software can inform the design of flexible parametric models.

In addressing this aim, my thesis occupies what Woodbury (2010, 66) has identified as the “common ground” between programming and parametric modelling, a space where currently “little explicit connection” exists between either side. In this thesis I consider how practices from software engineering may connect with practices of parametric modelling, which I do by applying software engineering concepts to the creation of parametric models. In chapter 3 I discuss which software engineering concepts may also be applicable to the practice of parametric modelling. I then select three of these concepts and apply them respectively to three parametric architecture projects in chapters 5, 6, & 7. The concluding chapters (chap. 8 & 9) bring these case studies together to consider how the design of software may inform the design of flexible parametric models and to consider the consequences of this relationship for architecture generally.

A limit of my aim is that it explores just one type of flexible digital modelling: parametric modelling. Not all architects use parametric models and for those that do, parametric modelling is but one technique in an array of modelling methods available to them. Flexibility may also be achieved through other methods like Building Information Modelling (BIM). The many advocates of BIM contend that BIM reduces rework (which creates flexibility) by creating a centralised repository of data that all representations draw upon; change the data once and theoretically everything updates (Eastman et al. 2011, 15-26). My research focuses on parametric modelling due to my experience with it and due to the opportunities for improvement this presents. However focusing solely on parametric modelling is not intended to be antagonistic to the other modelling methods. On the contrary, since architects often integrate modelling methods together, improvements to the practice of parametric modelling could manifest themselves as improved parametric features for other flexible representations like BIM.

A Note on Language

Within this aim, and throughout this thesis, I frequently use the terms parametric model and software engineering. Both are contentious. To help clarify my intended meaning I will briefly pause here and explain why I have included these terms.

Architects assign a range of meanings to the phrase parametric model. A number of definitions have been advanced that range from style-based classifications, to software zealotism, to arguing that all design is inherently parametric. Neil Leach claims that the disagreement is so fierce “few people in the West working at the forefront of computation use the term parametric” (Leach and Schumacher 2012). I however have chosen to use parametric in this thesis because parametric has a very precise historic meaning. The range of contemporary definitions are an illustration of how the modern conception of parametric modelling has shifted. I explore these shifts further in chapter 2. In the same chapter I explain the definition I use in this thesis: a parametric model is set of equations that express a geometric model as explicit functions of a number of parameters.

“The phrase software engineering was deliberately chosen as being provocative” write the authors who coined the term at the 1968 meeting of the NATO science committee (Naur and Randell 1968, 13). The original intention was to ground the practice of manufacturing software in a theoretical foundation similar to other engineering disciplines (Naur and Randell 1968, 13). Many have since argued that engineering is an inappropriate discipline to base the identity of programming upon. This has led Tom DeMarco (2009, 95) to declare “software engineering is an idea whose time has come and gone.” Others have said the manufacture of software is more like a design discipline (Brooks 2010), or a craft (Seibel 2009), or an art (Knuth 1968). It lies outside the scope of my research to resolve this forty-year old debate. In this thesis I use the phrase software engineering not because it is an apt analogy for what programmers do but rather because software engineering is a term still a widely used to denote the body of knowledge concerning the creation of software.

1.4 – Methodology

Previous research indicates there are methodological challenges in developing a convincing understanding of flexible parametric model design. When software engineers have sought similar understandings of software design, the researchers have shown a tendency to seek elegant, repeatable, statistical studies – perhaps owing to the mathematical and scientific origins of computer science (Menzies and Shull 2010, 3). Achieving this elegance, repeatability, and statistical confidence often requires the simplification of complicated circumstances. Turing award-winner Edsger Dijkstra (1970, 1) has stated that these simplifications inevitably lead computer scientists to conclude with the assumption: “when faced with a program a thousand times as large, you compose it in the same way.” For certain problems this extrapolation works, but on problems concerning software flexibility and maintainability, Dijkstra (1970, 7) argues idealised experiments fail to capture the paramount issues of “complexity, of magnitude and avoiding its bastard chaos.” In other words, simplifying, controlling, and isolating the issues of practice with a positivist or post-positivist perspective may generate convincing empirical evidence for software engineering researchers, but there is reason to suspect the simplifications will also abstract away the crucial parts of what needs to be observed to produce convincing evidence for practitioners.

With complicated interrelationships and the pressures of practice likely to be important components of this research, a primary consideration is how to avoid obscuring the nuances of practice whilst observing it. One method is to conduct the investigation from within practice, a method Schön (1983) describes as reflection in action and reflection on action. This method has a constructivist worldview where, according to Creswell and Clark (2007, 24), multiple observations taken from multiple perspectives build inductively towards “patterns, theories, and generalizations.” While this may be closer to social science than the hard science origins of software engineering, Andrew Ko (2010, 60) argues such an approach is “useful in any setting where you don’t know the entire universe of possible answers to a question. And in software engineering, when is that not the case?” The challenges of understanding practice therefore becomes one of generalising results that are not necessarily representative because they are based on observations of projects that cannot be simplified, controlled, and isolated. To help mitigate these challenges my research draws upon multiple research instruments to make the observations, and multiple case studies to triangulate the results.

• Multiple case studies: By employing multiple case studies, the anomalies of one can be balanced by the rest. Robert Stake (2005, 446) calls this a “collective case study” where multiple projects “are chosen because it is believed that understanding them will lead to better understanding, and perhaps better theorising, about a still larger collection of cases.” Chapter 4 discusses in greater detail the criteria for selecting the three case studies.
• Multiple research instruments: A research instrument, as defined by David Evan and Paul Gruba (2002, 85), is any technique a “scientist might use to carry out their ‘own work’.” Typical examples include interviews, observations, and surveys. Unfortunately there is no research instrument to measure parametric flexibility. Chapter 4 investigates how various qualitative and quantitative research instruments, many borrowed from software engineering, can aid observations of parametric flexibility. These are combined in various ways within the case studies to present a fuller picture of the various projects.

Whilst this triangulation of observations through a mix of research instruments is not as precise as a controlled experiment, it does aid in observing the influence of actions undertaken in the midst of large, messy, and complicated practice based projects – the situations where the flexibility of parametric models is critical.

I should also note (prior to discussing the thesis structure) that the chapter sequence in this thesis does not trace how I conducted the research. As a work of reflective practice I gathered the evidence of my research in a process resembling Kemmis and McTaggart’s (1982) cycle of “planning, acting, observing and reflecting” on actions in practice. In this sense my thesis represents a final extended reflection on my prior cycles of research. I use three of these cycles as case studies but there are also many incomplete and tangential cycles that are left unstated. As such, my thesis structure does not mirror my research process, and instead it follows a logic intended to contextualise the case studies in order to reflect upon the relationship between software engineering and parametric model design.

1.5 – Thesis Structure

This thesis is divided into nine chapters: the current introduction, three background chapters, three case study chapters, and two concluding chapters.

In the following chapter (chap. 2) I expand upon the challenges associated with parametric modelling that I have outlined in this introduction. I first examine the various definitions of parametric modelling and consider how these frame an understanding of what a parametric model is. I go on to reveal the numerous challenges architects have faced when using parametric models in practice. Aggregated together, these accounts reveal an array of problems that tend to be overlooked in many of the discussions around parametric modelling.

In chapter 3 I contrast the challenges of parametric modelling to the challenges associated with software engineering. I introduce the body of knowledge associated with software engineering and hypothesise about which knowledge areas may also help the practice of parametric modelling.

In chapter 4 I discuss a research method for applying aspects of the software engineering body of knowledge to the creation of various parametric models. I outline criteria for selecting the case studies and I discuss how a variety of quantitative and qualitative metrics can be used to observe parametric flexibility.

Each of the subsequent three chapters is a case study that takes an area of knowledge identified in chapter 3 and observes impact on parametric modelling with techniques from chapter 4.

In chapter 5 I explore the differences between creating a parametric model with a logic programming paradigm compared to creating a model with a more conventional dataflow paradigm. The logic programming paradigm enables the reversal of the parametric process by turning static geometry into a parametric model. However, outside this niche application, logic programming proves to be a difficult modelling interface.

In chapter 6 I consider how the principles of structured programming apply to the organisation of parametric models. Splitting models into hierarchies of modules appears to increase the legibility of the models and improve model reuse. Perhaps more importantly, the structure seemed to allow ordinarily pivotal decisions to be made much later in the design process – in some cases, moments prior to construction.

In chapter 7 I draw upon innovations in software engineering Integrated Development Environments (IDEs) to create an interactive programming interface for architects. The interface enables designers to modify their code and immediately see the geometry of the model change. This case study positions the scripting environment itself as a important site of innovation, a site where many programmers have already provided numerous useful innovations.

These three chapters feed into the discussion (chap. 8) and conclusion (chap. 9). I argue there is a close relationship between software engineering and parametric modelling. This relationship has implications for how parametric modelling is taught, for how parametric modelling is integrated in practice, and for how we discuss parametric modelling.

Thesis Navigation

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

Bibliography

Illustration Credits

• Figure 1 – Lincoln Laboratory 1964
• Figure 2 – Lincoln Laboratory 1964
• Figure 3 – Lincoln Laboratory 1964
• Figure 4 – Lincoln Laboratory 1964