Meatspace
Meatspace is a word I first heard a few weeks ago. It’s used to describe the human realm that’s not capitalizing artificial intelligence. It’s slightly derogatory and its users slightly smug. It implies that that part of the human realm is full of losers. Not on the winning team. I know I’m being repetitive but it’s what Water Gropius must have thought of craftspersons exactly one hundred years ago. Architecture’s relationship to new technologies hasn’t changed.
The saying “When all you have is a hammer, everything looks like a nail.” seems to have been around since the 1960s and is usually attributed to Maslow. It means that If a person is familiar with a certain, single subject, or has with them a certain, single instrument, they may have a confirmation bias to believe that it is the answer to/involved in everything. I feel it describes the current mood towards artificial intelligence and architecture. The only difference is that the nails don’t quite fit our new hammer. Architecture will work to redefine nails until they do.
It’s not just those of us who teach it who think so, but this thing called the design process is often assumed to begin with a definition of the problem. It’s not a bad way to start because, at the end of the process, it provides a standard for knowing if the problem has been satisfactorily solved. Ideally, decisions taken along the way will have worked towards solving the problem and not away from it. It means that the beginning of the design process is there at the end. It also means that the end of the design process is already folded in at the beginning and, by extension, that open-ended design problems don’t exist. [Where do the self-called “research-based practices” find their clients? Only the monied collector or PR-driven client would pay for research only tangentially related to getting them a building.] Nevertheless, different types of problem produce different types of architecture and there’s room for them all. No one of them is intrinsically superior. Was it Paul Rudolph who said of Mies van Der Rohe that he made wonderful buildings only because he chose to solve so few problems?
The stage of the design processafter definition is usually called analysis and usually includes a study of ways similar problems have been solved and, if (like Mies) one has experience of solving problems one sees as similar, then so much the better. Here again, if one has jn the past successfully solved design problems according to some personalized design process or system, then the hammer and nail analogy kicks in again. No two problems are ever exactly the same but unnecessary reinvention of the wheel isn’t the answer either. Some people call this dataset “case studies” and, at least in universities, they strongly influence the outcome even though the data can often be more of a wish list. The word “precedent studies” is in play at other institutions but, in addition to simply denoting something that happened prior, it invests the case study with an almost legal authority to determine the outcome. Even the term “reference” is dubious because it implies pre-selection and a somewhat predetermined outcome. What turned out to be useful is something one only knows at the end. Data scraping is said to be analogous and it probably is inasmuch as it draws conclusions from a necessarily limited and preselected data set.
The third and final stage is said to be synthesis and is where all the data is somehow synthesized but it’s really just a word we use to describe something we no nothing about. [c.f. The Mystery of Beauty]
• • •
One useful concept in the field of project management is that of dependencies between different tasks in a process. There are four types.
| Finish to Start |  | Predecessor must finish before Successor can start. [Land must be purchased before road building can start] |
| Start to Start |  | Predecessor must start before Successor can start. [Road excavating must start before Asphalt can be laid] |
| Finish to Finish |  | Predecessor must finish before Successor can finish. [Laying Asphalt must be complete before line painting can be completed] |
| Start to Finish |  | Predecessor must start before Successor can finish. [Road excavating must start before line painting can be completed] |
The first is Finish to Start. It’s the easiest to understand and is generally how we imagine those three main tasks in the design process to be connected. Life is simple when one thing finishes and another starts. Calling design a process implies some sort of connections between what we see as the three main tasks. But there are four ways each of those tasks can be connected. In the above, I described them in the sequence they are conventionally understood to occur, even if there is some recursiveness along the way. Thinking of the three stages of the design process as a sequence makes sense and seems to fit our observations but those three tasks have two links that each could be one of four ways. This is already sixteen different ways that can potentially describe the design process. Synthesis could begin the moment the problem is defined. It could take place at the same time as analysis. And so on. Moreover, if synthesis prompts a redefinition of the problem, then there’s a third link between tasks and now 32 different ways the process can go. Sometimes it’s the case that solutions go looking for problems. It’s more complicated than we thought but it’s not unknowable.
Start to Finish could be an equally good fit for a design process that only begins once the end result is known. In this case, the desired outcome is embedded in how the problem is framed and drives both the analysis and synthesis. It’s working towards a known conclusion that could be totally wrong but who’s to know that? It happens all the time in architectural education and it’s difficult to explain that, although designing what you want to design might work sometimes, it’s no guarantee it always will. As soon as a project begins, a student might already have an idea of what they’d like to do. It’s often just impetuousness but intuition can sometimes be right. Architects with more experience do this all the time and we call them experienced if they’re not famous and creative if they are.
If the design process were rigidly sequential and always using the same references and parameters then we’d expect the results of limited competitions to converge but this never happens. An OMA building is never going to look like an SOM or a ZHA building or a HOK building. If an infinite number of Frank Gehrys and OMAs were given an infinite number of projects and a sequential define-analyze-synthesize design process, then sooner or later you’d expect OMA to design a Frank Gehry building and Frank Gehry to design an OMA. We don’t expect this to ever happen. The definition-analysis-synthesis model may be useful as an educational model but it doesn’t account for architecture as it is performed. It might even be an architectural myth.
More relevantly, if the end of the design process is already there at the beginning, then there’s little point scraping datasets to train algorithms to mimic a design process that’s either bogus or misunderstood to begin with. However, there’s still the possibility that intuition and inspiration are just different names for the same old one-two-three design process we understand, but compressed to the extent that the solution appears to come from nowhere and instantly. This simpler explanation involves no torturous logic and hints at the awesome processing power of the human brain when we put our mind to something.
• • •
All the above has assumed this process is conscious even if it cannot be explained. Now I’ve come to the end of this post, I realize that the project I ended the previous post with was a mat-building iteration of Ricardo Bofill’s Les Teraces du Lac. Where did that come from? I don’t know, but it is. Now I know this, I might take the project more in that direction but, if I’d started out by wanting to recreate Les Teraces du Lac as a mat building, it probably wouldn’t have worked. I’m not trying to raise the bar in the synthesis vs. pattern-matching stakes but our model of how the brain functions and creativity works could be more than highly cognitive, cold-blooded rationalism and also have a component that’s not only inexplicable but unconscious as well. This would mean that, when we perform a creative task, we scan our personal databases for not only what we think is relevant but everything that’s potentially irrelevant as well. This is a huge problem for coders because the creativity database just became unknowably large. This isn’t to say that a wonderful solution could still be found if, like Mies, we ignore entire dimensions of the problem.
• • •
Share this:
