My hall-mate Bill Higgins has often recommended the book "How Buildings Learn" by Stewart Brand as "the best book about software design that never mentions software". He's right, it's a great book, and although it doesn't talk about software, there's a lot to take away from a software perspective.
In general, Brand's premise is that most buildings have fairly long lives, and end up serving multiple distinct uses during their lives. Those uses end up forcing the buildings to change, and much of the book discusses aspects of buildings that work in favor of buildings successfully changing to suite new uses, and factors that work against it.
In terms of software, I think one of the sins we most frequently commit is not future-proofing our products. If your product is successful, it might well have a very long life. Have you constructed it such that it can easily be modified to handle future requirements placed on it? The answer is typically, no. For example, see Steve Northover's "API grows like fungus!".
I don't want to spoil the book for you, but I will advise you to do this: after reading a section of the book , spend a little time imagining how what you just read applies to software development. It doesn't all apply; but a lot does.
If you've already read the book, you'll get a kick out of the following article from Slashdot this week:
If you haven't read the book, here's a little spoiler; Brand spends a number of pages complaining about a different "modern architecture" building on MIT's campus, the Weisner Builder. Brand also spends a fair bit of time complaining about problems endemic to modern architecture, including leaks, and included the following quote talking about Frank Lloyd Wright:
His stock response to clients who complained of leaking roofs was, "That's how you can tell it's a roof."
Note Brand's book was published in 1994; construction on the Stata Center (Gehry's building) began in 2001. The Stata Center replaced Building 20, which was the 'vernacular' building that Brands praised so highly. Buildings might learn, but people apparently don't.
The only real complaint I have is the form factor of the book. It's 11" wide by 8.5" high (or so). The only comfortable place I've found to read it is in bed. I assume the layout was chosen because the large number of photos included in the book; it might well have been the only practical way to publish it. But it does seem a bit ironic, for a book that is pushing "function over form", to be such a difficult physical read.
Highly recommended.
1 comment:
It is an excellent book. I hadn't thought of using it as a software engineering text, but you're right, there are some strong parallels.
One of Brand's theses is that our short term vision is built into the planning cycle. Buildings are only meant to serve a single purpose; they are only intended to last a few years (40ish in North America); and they are not maintained by those who build them.
Tie that to software engineering and you can see the same antipatterns reoccurring: as you say, software is not designed to handle future requirements and repurposing. Software engineers typically intend to create a new version of their software, meaning that they don't plan for future events (such as the Y2K rollover, or the additions of new protocols after the original company has stopped supporting the software). And, of course, the last point jives nicely with OTI-style software engineering: the people who write the software must support it.
Post a Comment