Notes on How Buildings Learn, Introduction

I’m ready to embark on my project of going through my margin notes in Stewart Brand’s How Buildings Learn.

But first, an introduction: after only ten pages, I began to suspect that Brand’s book might be the book on brick-and-mortar architecture that says the most about software “architecture.” To explain what I mean, I want to repeat a quote from the book:

“Porches fill in by stages, not all at once, you know.” The architect [whose name Brand didn’t get] was responding to a talk I gave at a builders’ conference. “The family puts screens on the porch one summer because of the bugs. Then they see they could glass it in and make it part of the house. But it’s cold, so they add a duct from the furnace and some insulation, and now they realize they’re going to have to beef up the foundation and the roof. It happens that way because they can always visualize the next stage based on what’s already there.”

What does this say? That houses are steadily, gradually changed – evolved! – and that home owners do this themselves – that they usually don’t need the help of an architect. Why? Because something suggests to them in which ways the house might be evolved.

I find this “something” very interesting. Because it is not just the house itself. It is also culture. Culture constricts its shape, and carries knowledge about past and proven solutions for changing its shape.

Brand makes the case that most of the money spent on a building is on maintenance, not actually building it in the first place. This is what Extreme Programming says about code, when it argues that one should get into “maintenance mode” as quickly as possible, by building a rudimentary but complete system to evolve, as opposed to building every part and assembling them to a system in the end.

Brand’s point is that much of architecture today neglects maintenance and adaptation, and his book tries to find out how buildings adapt – how they learn – to see in what ways architecture needs to change.

In software development, despite the gaining popularity of agile methods, the trend still is to distinguish between “architects” and mere developers, and to see design as something that is to be completed before implementing. First come the architects and draw boxes and arrows, then the developers to churn out the code. Modern development tools are designed to dispense of developers, by generating the code directly from the boxes and arrows.

What software development needs is to stop imitating the illusion of what brick-and-mortar architecture is. According to Brand, brick-and-mortar architecture itself is in a state of illusion, having lost the knowledge of how to successfully build functioning, adaptable houses.

More to come.

The above was posted to my personal weblog on February 20, 2005. My name is Peter Lindberg and I am a thirtysomething software developer and dad living in Stockholm, Sweden. Here, you’ll find posts in English and Swedish about whatever happens to interest me for the moment.


Related posts:

Posted around the same time:

The seven most recent posts:

  1. Tesugen Replaced (October 7)
  2. My Year of MacBook Troubles (May 16)
  3. Tesugen Turns Five (March 21)
  4. Gustaf Nordenskiöld om keramik kontra kläddesign (December 10, 2006)
  5. Se till att ha två buffertar för oförutsedda utgifter (October 30, 2006)
  6. Bra tips för den som vill börja fondspara (October 7, 2006)
  7. Light-Hearted Parenting Tips (September 16, 2006)