A look at how Stewart Brand’s classic work of social and architectural criticism, How Buildings Learn, applies to web design and development.
First, if you are in any way interested in design, history, or architecture, which I assume you are by your presence here, read the book How Buildings Learn: What happens after they’re built, by Stewart Brand. Building on Jane Jacobs’ classic criticism of city planning, The Death and Life of Great American Cities, Brand looks at what happens to buildings over the fourth dimension: time.
As I began to read How Buildings Learn, the initial concepts tickled me as familiar in a way that great and simple ideas often do. When written clearly, they seem obvious. However, when we look at the world around us, these ideas are clearly not obvious – or if they are obvious, they are ignored. Further in to the book, the basis for this familiarity becomes more obvious. Idea after idea and concept after concept, clear parallels emerge between the architectural issues dealt with in the book, and those issues we deal with every day as web developers.
Brutally oversimplifying Brand’s premise, he argues that modern architecture and building practises are ignoring what happens to buildings after they are built. Buildings are designed to be impressive on opening day and in 3D computer models, but not to be livable in the long term. When the ribbon is cut on opening day, many architects see their jobs as finished. So too are many websites designed to look good in the portfolio of the designer, no deeper than the front page. They aren’t designed to be lived in – they are not designed to be used, either by the visitors or by those who maintains the site.
Building for Change
Brand’s most fundamental edict is that of building for change. Perfection is a doomed goal. When building, whether it be a house or a website, if you try to freeze time and build for a perfect present (or your own concept of an ideal future), you are damning those that will maintain your creation to work within your flawed construct of perfection. Aware of this pitfall, the time-aware builder puts trust in the knowledge and experience to be gained by the tenants of his creation. He knows that after 10 years of living in a building (or ten months of managing a website), the original builder is no longer the expert. Rather, those who have come to occupy the building will be the experts – having dealt with the thousands of small challenges and decisions that confront an occupant through the years.
One, two, or three years after you’ve built a website, there is a strong chance that someone else will then know a lot more about it than you. They may thank you for your clear foresight in not over-specifying the structure of the site. They may also curse you for choosing a proprietary database or for not documenting your code.
Brand highlights the practises of builder / designer John Abrams as a great example of how to document your design for the next generation of occupants and builders. During construction, Abrams would photograph each wall before it was closed in – capturing the position of all service elements (electrical wiring, stud-spacing, plumbing, etc.). These photos were eventually compiled into a book that was passed on to the owner of the building when construction was finished.
The clearest parallel to this type of documentation in the web world is documenting and commenting of code. Code should be written and documented in a style that intends an audience other than yourself. Other seemingly trivial examples can be a life-saver for long-term maintenance, such as keeping original photo and vector art files or documenting and storing any fonts used in the project.
Use Local Materials
Brand also suggests that designers and builders use, as much as possible, local materials. Wood and masonry from the locale of the building site is far more likely to be available down the road when needed for repairs and replacement. While exotic masonry or roofing tiles may be an enticing conversation piece, it will turn into a maintenance nightmare when they start to crumble and the next owner of the building is unable to find suitable repair and replacement materials.
As there isn’t really such a thing as ‘local materials’ when it comes to web development, we must abstract the advice: Use materials that will be easy to maintain and build upon in the long run. While much has been said of the long term benefits of standards compliant XHTML on the front end of web development, little has been said of the long term effects of the back-end structure and choice of development platforms. If your site happens to be a collection of static pages, then strict XHTML compliance and careful structuring of code will help ensure long-term access to the content. However, many sites are more like an iceberg, with the generated HTML showing only a hint of of the server-side programming that lies beneath the surface.
In an extreme but brilliant example of ensuring ample maintenance supplies for future generations, Brand tells of a story by anthropologist / philosopher Gregory Bateson [sic]:
New College, Oxford, is of rather late foundations, hence the name. It was founded around the late 14th century. It has, like other colleges, a great dining hall with big oak beams across the top, yes? These might be two feet square, forty-five feet long.
A century ago, so I am told, some busy entomologist, went up into the root of the dining hall with a penknife and poked at the beams and found that they were full of beetles. This was reported to the College Council, who met in some dismay, because where would they get beams of that calibre nowadays?
One of the Junior Fellows stuck his neck out and suggested that there might be on College lands some oak. These colleges are endowed with pieces of land scattered across the country. So they called in the College Forester, who of course had not been near the college itself for some years, and asked him about oaks.
And he pulled his forelock and said, “Well sirs, we was wonderin’ when you’d be askin’.”
Upon further enquiry it was discovered that when the College was founded, a grove of oaks had been planted to replace the beams in the dinning hall when they became beetly, because oak beams always become beetly in the end. This plan had been passed down from one Forester to the next for five hundred years. “Your don’t cut them oaks. Them’s for the College Hall.”
A nice story. That’s the way to run a culture.
Excerpt from Stewart Brand’s How Buildings Learn.
The true architect builds with a clear understanding of the limitations of his current vantage point, before a building exists, rather then blindly ignoring them. When building your next web project, be sure to plant oaks for the next developer.
Embracing the Low Road
Building well architected systems with well thought-out directory and file naming schemes and well commented code is all well and good when you have the time and resources. However, what about that little side-project that you don’t really have time to do anyhow? You’re not getting paid much for it, and you don’t have time to do as good a job as you would like.
That’s fine, as long as you keep a few simple things in mind. The method of building and designing that Stewart Brand argues we need is not one of big budgets and over-planning. On the contrary, Brand embraces simplicity, common sense, and frugality in what he calls the low road.
“A young couple moves into an old farmhouse or old barn, lit up with adventure. An entrepreneur opens shop in an echoing warehouse, an artist takes over a drafty loft in the bad part of town, and they feel joy at the prospect. They can’t wait to have at the space and put it immediately to work. What these buildings have in common is that they are shabby and spacious. Any change is likely to be an improvement. They are discarded buildings, fairly free of concern from landlord or authorities: “Do what you want. The place can’t get much worse anyway. It’s just too much trouble to tear down.”
Low Road buildings are low-visibility, low-rent, no-style, high-turnover. Most of the world’s work is done in Low road buildings, and even in rich societies the most inventive creativity, especially youthful creativity, will be found in Low Road buildings taking full advantage of the license to try things”
Excerpt from Stewart Brand’s How Buildings Learn.
Your quick and dirty little side project is not intended to be a monument for the ages. You’re not building the pyramids here – you’re just trying to get something done on time and on budget (if there even is a budget). Brand’s low road of building and architecture is all about quick and dirty solutions. The redeeming feature is that it be quick and dirty enough that you can tear down or dramatically renovate without anyone missing the original.
The second key to building on the quick and dirty low road is to remember that even if you don’t intend something to be used for very long, if may well be.
Temporary is Permanent
Architecture is full of examples of hastily built buildings intended for a temporary use living long and fruitful lives well beyond the scope envisioned by their original builders. This phenomenon is sure to be familiar to most web developers; that web site for the university department that you built in an afternoon in 1998 is still up; that sloppy web-based application system you doubted would even work then somehow went on to handle loads of traffic.
We’ve all had projects like these. The next time you go to build something “quick and dirty” or do an ugly hack on an existing system, remind yourself that this code will probably live on far longer than you may intend.
These are only a few of the parallels between Brand’s great work, How Buildings Learn, that can be applied to web development. The book is full of other anecdotes and examples that can help any web designer or developer.
During a recent conversation about software upgrades (to which I am a 
