It has become unusual to design architecture without computers, but the convenience and expedience come at a price. Many firms now must spend time developing their own algorithms, scripts, and plugins to coax the software into producing the designs they want. To aid this process, they often hire computational designers and expect their design staff to be familiar with computational concepts, such as programming and parametric modeling.
Although many architects can program, they don’t program like software engineers. In the book Elements of Parametric Design (Routledge, 2010), Robert Woodbury, a professor at Simon Frazer University, in Vancouver, Canada, describes designers as “amateur programmers.” They do enough to accomplish the task at hand, but they don’t have the time or inclination to do it strategically.
Software engineering is a relatively new field compared to architecture, but it has already established a culture of project delivery. While we may marvel at a software engineer’s skill in programming, we should really admire their ability to execute a complicated product on time and on budget. Central to this process is a suite of management techniques and tools that technology companies use to guide their software engineers. As programming becomes more commonplace in architectural design, a few architecture firms have begun considering whether they should work more like software engineers. Nathan Miller, founder of the technology consultancy Proving Ground and my former colleague at Case Inc., says, “Modeling a building with BIM is more akin to designing a piece of software [and less like] using CAD, which is more like using graphite.”
NBBJ, based in Seattle, is trying to improve its computational design process with knowledge from software engineering. Marc Syp, the firm’s digital practice leader who has worked in the architecture industry and at Flux (a startup from Google that is trying to reinvent the architectural design process), says that most of the insights he gained the startup world “are completely absent from the architecture world.”
Syp and his team, which oversees technology adoption, use, training, and standards, are trying to change the way NBBJ approaches computational design. He wants the staff “to think about ourselves as software engineers—not just talking about it but following the processes of software engineering.”
As the team that vets the technology for the company, they are currently experimenting with a number of tools that are standard in tech companies: messaging platforms like Slack to reduce internal emails; project management software like Asana to keep running task lists; and source-control systems like Bitbucket to track changes to files.
Miller, who formerly was also a member of NBBJ’s digital practice team, says that when it comes to adopting technology, “project management is the part of practice that is the hardest to move because it has the most to lose.” While many architects experiment with scripting and parametric modeling during discrete parts of the design process, they have been hesitant to adopt management techniques that have long-term implications for project schedules and budgets. “Given how architecture is being done—with architects using computers to quickly iterate—the fundamentals of project management need to adapt,” he says.
Miller is currently helping the design technology team at HDR Architecture, headquartered in Omaha, Neb., to adopt a management technique called “scrum,” which is popular at tech-centric firms such as Adobe, Amazon, and Spotify. Scrum emphasizes quick iterations and adaptability over long-term planning and Gantt charts. It has a fairly prescriptive process and a unique lexicon. Work is conducted iteratively, in two- to four-week “sprints.” At the start of a sprint, the entire team meets to determine the “backlog”—the set of tasks to be completed during the sprint. In architecture, the backlog may be a set of features to add to a parametric model or a list of outstanding items in a construction-document set.
Often the backlog is displayed on a whiteboard or website so the entire team can monitor what has been completed during the sprint. As part of the sprint, the team meets for daily “standup meetings” where each team member announces what they’re working on and what is holding them up. Everyone is physically standing so no one is tempted to talk for too long.
At the end of the sprint, the team has ideally completed every task in the backlog and has something tangible to give the customer; in the context of architecture, this is often a project milestone. The final step is a retrospective to identify ways to improve the next sprint.
Woods Bagot is experimenting with scrum in their design-technology group. “It is 10 times better than what we were doing before,” says Shane Burger, the firm’s New York–based director of design technology. To make scrum work at an architectural practice, Burger has had to make a number of adaptations. For example, Woods Bagot has offices on five continents, which makes it impractical to hold daily standup meetings since the group spans many time zones. Instead, Burger holds a weekly meeting where they cover topics similar to what they would have had a typical daily standup meeting. Though the group is finding it challenging to package the firm’s work into sprints and has only used scrum on internal projects to date, Burger is confident that they will soon apply it more widely.
In many ways, the recent changes in management operations at Woods Bagot, HDR, and NBBJ represent a new era of computational design. Currently, the role of computation has manifested in the form of buildings by the likes of Zaha Hadid, Hon. FAIA, and Frank Gehry, FAIA, but not necessarily the structure of their practices. This superficial era of computational design appears to be ending with a new generation of firms looking to apply lessons of software engineering to all aspects of practice—from file storage to project management and even client interaction.
