Back in early August, I had the privilege of speaking at USC’s annual BIM Symposium on the topic of visual programming. This post is my attempt at a sort of editorial that follows the narrative of that talk. Along the way, I’ll include a few of the videos that I shared at the presentation which hopefully demonstrate the kind of tool creation I’m talking about. Hope you enjoy.
It’s been 5 years since we officially launched our research program at the Yazdani Studio of Cannon Design. During that period we’ve come to understand that the evolution of our process reflects the larger, changing relationship architects have with their means of production. We’ve always been a profession of hackers. Every building is a one-off made up of countless elegant hacks, each bringing disparate materials and systems together into a cohesive whole. But when it comes to the software that designers have come to rely on, most of us have been content with enthusiastic consumerism, eagerly awaiting the next releases from software developers like Autodesk, McNeel and Bentley. In late 2007 something changed. McNeel introduced a visual programming plugin called Grasshopper authored by David Rutten, and more and more architects began to hack their tools as well as their buildings.
With all the buzz around bespoke products and novel technology, it’s easy to forget that we still live in an off-the-shelf world. Most things aren’t made-to-order and the software designers depend on is no different. The program a Hollywood studio is using to create special effects is often the same one an architect uses to study a design idea. It makes sense for software companies to invest in developing tools that serve large market sectors. It also makes sense for small businesses to borrow tools from larger industries. But what about all those little process idiosyncrasies that make design studios unique? Chances are a general-purpose, cross-industry application isn’t going to be a 100% compatible with the way you do things.
Since the introduction of AutoCAD in the early 80’s, architects have struggled to find a comfortable way to take advantage of efficiencies promised by digital production tools without sacrificing their signature moves. In the 90’s, Frank Gehry famously adapted CATIA – software that was originally developed for designing fighter jets – to enable the construction of the complex geometries the firm was trying to create. The result, Digital Project, was developed and supported by off-shoot technology company Gehry Tech. For the rest of the industry, maintaining a team of dedicated programmers, or even retaining architects that became skilled at programming, has proven difficult. Most often, artists and architects have had to choose a compromise between their design process and the functionality offered by the software available on the market. A new generation of visual programming tools is giving designers an alternative: the ability to tailor their applications to the specific way they work – without the team of dedicated programming wizards.
Visual programming is part of a larger classification of tools that support end-user development or EUD. EUD is the developers answer to the need for user customization and automation. Most popular software packages ship with a way to modify, or even create functionality, and automate repetitive tasks. Rhino has RhinoScript, Revit has DesignScript, 3dsMax has MAXscript, Maya has MEL, just to name a few. In reality, there are only a relatively small group of actual end-users that can use these scripting languages with any proficiency, and the few that can, quickly become specialized. Fortunately, an ever expanding roster of visual programming software like Grasshopper, Dynamo, Generative Components, 3dsMax’s MCG, and Marionette for Vectorworks are giving designers access to EUD without any prior knowledge of a programming language. By removing this barrier to entry, visual programming is quickly making EUD in architecture an every-project occurrence.
The popularity of software like Grasshopper and Dynamo suggests that the relationship architects have with their tools is changing. We’re moving away from passive adoption of off-the-shelf software to actively engaging in hacking these tools to better fit our design process. Can’t find a program that does what you want? Make your own. It’s a practice that has the potential to counter the industry-wide homogenization that has left many artists and designers skeptical of the benefits of design software.