How Buildings Learn is a 6-part BBC TV Series from 1997 hosted by Stewart Brand. Brand has been researching and writing about architecture and various buildings trying to answer the question “What happens after they’re built?”.
What happens to buildings after they’re built? That’s when the users take over and begin to reshape the building to suite their own real needs.
This is a beautiful question. How does architecture grow and adapt to newer and newer demands from users over time? Architecture is a very common web development analogy and I can’t help but make correlations from How Buildings Learn. What are the characteristics of successful long-term architecture and do they apply to web design? And maybe more importantly, what design choices only serve the short-term?
Some of our more arrogant and careless buildings are at war with time and change. And they always lose. Some buildings though seem to flow with time, they flow with us.
When building sites, we tend to cram in the latest and greatest in New Shiny Techonology™. Slick parallax scrolling that just needs to be bulldozed. We’ve come to expect expensive redesigns every couple years.
We’re also under pressure to build new features quicky. Build quick and look impressive, with all the latest trends.
The desire by architects, planners, and politicians to impose a style without planning for long term use, change, and adapability can cause all kinds of problems. In Paris, Mitterrand’s Grands Projet have had sortid disasters. Built quick to look impressive, these buildings have had a terrible maintenance record.
How does this grow over time? How does this adapt and change? Is it a pain to maintain? These are questions are very relevant as I help clients build and improve responsive design systems.
It’s rare to consider the long-term maintenance cost of a design decision. Sign off happens before the overall cost is tallied. Or before you even really know the problem you’re trying to solve.
There’s a phrase in React’s Design Principles that I struggle with: “Code is disposable and often changes”. In some ways, thinking of code as disposable is great, it encourages you to continuously adapt; no golden calfs. But in other ways, it encourages you to embrace only the short-term.
Brand’s series and research is thought provoking. Maybe web development is more disposable than architecture and the analogy falls apart? Or maybe bad architecture is just plain bad architecture.
/via Adam Keys and his post “Three Nice Qualities”