Your browser is no longer supported

For the best possible experience using our website we recommend you upgrade to a newer version or another browser.

Your browser appears to have cookies disabled. For the best experience of this website, please enable cookies in your browser

This site uses cookies. By using our services, you agree to our cookie use.
Learn more here.

The Ghost in the Machine: Programming and Architecture

Robert Aish shares his insight as the software developer whose application was used to design the Olympic Velodrome

There are virtually no buildings completed today where aspects of the design or construction have not harnessed computing in some shape or form. But this broad generalisation masks a contrasting spectrum of differing software tools and levels of intellectual and creative engagement. It should go without saying that the software developers who write computer-aided design applications have a tremendous vested interest in the process of design and in the architecture that results from that process. However, any shared vision of architecture and the process of design that links architects with these software coders can seem absent or obscure.

Architecture is an integrative endeavour, spanning multiple disciplines and modes of thinking so what should be the role of coding and computation in architectural design? Perhaps merely to help to make life easier, but let us dig deeper. One answer might be to provide automation tools, such as drafting. These implicitly accept current practice as a given and focus on providing productivity benefits. In this context, such tools should be easy to retrofit to existing design practice; should present established terminology and conventions; and should be usable with minimal knowledge of computing or specialised training. This is the era of ‘office automation’, of the word processor. A word processor can help in the mechanics of writing, but embeds no conceptual knowledge about the user’s thought process and therefore offers no support to complement the user other than speed.

It has become clear that the ‘drafting automation’ approach (the design equivalent of the word processor represented by CAD packages) may offer designers some immediate advantages but essentially fails to make any engagement between the fundamentals of computation and architectural creativity. In many other professional domains the application of computers has been the motivation for far more profound changes.

Let us start with the basics: a computer program and a text book can both embed conceptual knowledge. The advantage of a program is that this conceptual knowledge is also available in an executable form. In most scientific and engineering domains the primary reason for using a computer application is to access this embedded knowledge. Therefore the use of the program in part depends on the user’s recognition that he/she may have to learn the core concepts on which the program is based. Acquiring this kernel of knowledge extends his/her horizons and is a benefit in its own right quite apart from the knowledge’s value in using the program. This does not mean that the program should not be intuitive to use, but more that it should engage with the intuition of the user to communicate rather than mask the underlying abstractions.

Geometry and specifically computational geometry is an underlying abstraction embedded in most design applications and forms an essential connection between computation and architectural creativity. Why draw straight lines and planar orthogonal forms reminiscent of hand drafting, when with a computer you can draw free-form curves and surfaces? Why draw free-form curves and surfaces when with scripting tools you could specify the design logic to control the form or proportion of the geometry so as to achieve some more subtle effect of transition or variation? Why be limited just to geometry when you could use form-finding techniques to create architectural forms that emerge from the interaction of generative logic, constraints and performance criteria?

This progression is not simply about design intuition and creativity. Nor is it simply about programming logic and engineering rationality. What is interesting is that this process is a combination, indeed the integration of different ways of thinking: design and engineering, intuition and logic, exploration and confirmation. Certainly, it is possible to draw complex geometry with traditional ‘hand-eye’ skills but computed or ‘form-found’ geometry harnesses deeper insights and creates an aesthetic that goes beyond intuition. The challenge for the software designer is how to present these deeper insights and these underlying abstractions in an intuitive form?

It is not for software writers to claim that the heroic architect-engineer-master builders of the past never thought in this more integrative way. What we are suggesting is that this ideal of integrative design could be more broadly encouraged by developing design software in a different way and by using it differently. Instead of writing separate computer applications for different design and engineering disciplines, we are seeing computational design tools emerging that combine geometry generation, interactive direct manipulation, scripted ‘design logic’ and multidisciplinary analysis and simulation all within a single application. Here we are moving on from the idea of the single practitioner using a single discipline-specific application in relative isolation to a new scenario where the computational design model, informed by different analysis and simulation tools, becomes a real-time intermediary between the members of a multidisciplinary design team. Such a system could be convincingly used on a discipline by discipline basis.

Of course the, often politicised, specifics of a particular project may require more formal separation of responsibilities but at least the software is providing the opportunities for such collaboration. But we need to remind ourselves that not all curvy parametric scripted architecture is the same. There is, for example, a world of difference between the the Velodrome’s and the Aquatics Centre’s computed geometries (AR August 2012). We can certainly identify those buildings which are the product of computational rationality; that use form-finding techniques to create architecture that is both intrinsically aesthetic and harness the laws of physics (possibly intrinsically aesthetic for the very fact that it does harness the laws of physics).

Such architecture can harness the natural shell structure, it can present a gentler profile to the elements. It has a greater volume to surface area ratio. It is naturally iconic. And when used within the community, for example as a school building, it can be inspirational, as the embodiment of the arts and sciences in harmony without the spiralling costs it is often fancifully accused of concocting. We can compare this with the less rational (or even non-rational) use of the same technology to create forms that pretend that they can circumvent the laws of physics, but actually end up having to be post-rationalised by unsung heroes in the back office.

Software can encourage and can facilitate − it cannot dictate. Code can be used deeply or superficially. Its use reflects, even amplifies the intent and the values of the users. Software developers don’t design buildings, they design software. But we have a tremendous interest in design both as a process and as a result. We have a vision of design based on creativity and knowledge, where the boundaries between disciplines dissolve and where architecture can achieve its potential as a true synthesis of multiple ways of thinking and as a physical artefact with important social and cultural dimensions.


Robert Aish was responsible for the development of GenerativeComponents (used in the conceptual design of the Olympic Velodrome) and is now director of software development at Autodesk where he is working on ‘DesignScript’. He gives a Broader View of software potential

Have your say

You must sign in to make a comment

Please remember that the submission of any material is governed by our Terms and Conditions and by submitting material you confirm your agreement to these Terms and Conditions. Links may be included in your comments but HTML is not permitted.