Learning from How Buildings Learn

The BBC miniseries based on Steward Brand's How Buildings Learn became available on the Internet a few days ago. It's chock-full of provocative stuff, and lays out compelling arguments about how structures succeed or fail in satisfying the needs and goals of people. (Let's hear it for design on TV! First Mad Men, now HBL. It's a televisual golden age!)

ferry_building.jpg The Ferry Building

As I watched the opening episode, I thought of the quintessential local example of a learning building: The Ferry Building in downtown San Francisco. Built in 1898, it served as a ferry terminal for points around the Bay; as San Francisco changed and bridges eased the traffic burden, it gradually fell into disrepair. In 2004, it re-opened as gourmet food court, serving the prosperous downtown lunch crowd. San Francisco changed, and the Ferry Building "learned" to address a new set of needs. Beautiful.

Is architecture really a good analog for IxD?

Aside from all of the fascinating examples of the ways in which our built environment responds (or doesn't respond) to change, what the miniseries reveals to me more than anything is the limitation of using architecture and construction as models for software design and development. Architecture serves as a helpful stand-in when you're talking about the macro stuff — the planning process, the rough apportionment of the screen "real estate," and discussions around extensibility or repurposing — e.g., Is this thing the first piece of the big structure, or is it the temporary thing that we live in while the big structure is built?

But when you're talking about the way people experience things in a digital environment, architecture is a limited analog. Software is made up of subtle, nuanced interactions and ever-evolving technical capabilities. Interacting with software is conversation between two active participants; it's fast-paced and packed with immediate possibilities. For example, changing context in software seems more akin to a change in facial expression than, say, a movement to a different room. (It should, anyway). The ever-evolving technical capabilities have created a world in which we're all often experiencing some particular digital interaction for the first time; in fact, if someone wrote a book about how software is experienced, it could be called something like, "How Software Teaches Us How to Use It."

Solutions begat problems, problems beget solutions

Of course, there's another side of Brand's perspective that's relevant to our work: Most design projects (at Cooper, anyway) begin with what is presented as a straightforward task: Design a solution for the problem the clients have identified. Architects probably experience a transformation similar to ours, because the real problem is often quite different than what the client has articulated. Brand's perspective is interesting to consider here, because our solution often simply modifies (or modulates) the problem -- makes it smaller, hopefully — but still: Will our solution be able to handle the need to evolve to further reduce the problem? Of course, if anything could learn and teach at the same time, it's software. But software that can learn ... Hmm. Something sounds fishy about that. Remember that part in Terminator where they're talking about how the computers took over?

[Start with Episode 1 of How Buildings Learn at Google Video, and thanks to smashingtelly for the tip]


Dave Cronin
I see your point about how digital software is different than buildings made of atoms, but your comparison feels focused on external shell or envelope of a building. On the inside, buildings and other built spaces can much more like those "nuanced interactions" with software than you give them credit for. Taking the simple, obvious comparison of Facebook to the archetypal student union building on a college campus. They are both large spaces intended for people to congregate and socialize. The success of both has to do with exactly how the "internal" space is organized in a combination of open-ended possibilities (tables for eating, studying, gossiping) and structured activities (pool tables, scrabulous).
Doug LeMoine
I see your point, and I like your Facebook example. The "interior" of Facebook facilitates social activity that is analogous to that of the physical structure of a union. This real/virtual mapping is another area where architectural metaphors seem to apply. The split that I wanted to pinpoint was slightly different, so let me define what I mean by "nuanced interactions." In the real world, a nuanced interaction is when, say, your girlfriend's eyes narrow when you utter the words "nuanced interaction" at a cocktail party. *You* notice it because you know her, you know that look, and you know what it means: "Do not geek out." Other people who are paying attention may understand it, too, because they're human and they understand the significance of narrowed eyes. This sense of subtle response to individual action is where I see software being different than architecture. In software, you're doing a lot in real time, and the software is changing in real time to respond to you. So, the point I attempted to make is that (really good) software is more like a humans changing expression in real time than a building reacting in real time to human action.
Dave Cornell
First let me compliment you on the design of this comment section - no login required, and a single letter to verify a human. Short but sweet, as I would expect from you :*) The line I'm writing about: "But software that can learn ... Hmm. Something sounds fishy about that." No - something sounds great about that! I daily repeat the exact same sequence of commands when using my OS, and it sure would be nice if the computer could "see" this and do it for me. Of course the trick would be to do it in a very transparent way. A real-world metaphor: I'm a busy executive, every morning I have a bagel/w cream cheese, coffee, and read the WSJ while I eat. My observant assistant, after a week of seeing this repeated, identical behavior, would do this for me in the morning. If my morning routine changed one day at the last minute, I'd interrupt my assistant and do the new activity. The next morning, they'd ask if I wanted the usual, and learn if this new behavior was a one-off or the new default routine. If a software assistant did this, it would save me time and frustration. I have good ideas on how to visually represent this, but that is for another post.
Doug LeMoine
Hi, Dave. I admire your optimism here: Perhaps it *is* possible to make software smart enough to adapt to common patterns of usage without becoming the kind of thing that wants to destroy the human race. It's a fine balance, but perhaps it can be struck. ;-]

Post a comment

We’re trying to advance the conversation, and we trust that you will, too. We’d rather not moderate, but we will remove any comments that are blatantly inflammatory or inappropriate. Let it fly, but keep it clean. Thanks.

Post this comment