November 24, 2018.
Some months ago, a friend recommended Christopher Alexander's A Pattern Language. I hadn't heard of it before, and as I started poking around I realized that this was the second of a series of three books, and recommendations generally pointed me to start instead with The Timeless Way of Building.
Delving a bit further into the context surrounding these books, I was surprised to learn that in addition to being an influential work on architecture, the genesis of the software design patterns community was from Alexander's works as well.
Stylistically the book ventured a bit too far into mysticism and gnostic wisdom for my taste—almost reminiscent of reading the Tao Te Ching at times—but it was an interesting read, particularly in its context as a foundational text.
What I took away from my read is a renewed focus on incorporating folks' needs and habits more tightly to what we create to enable them, and a reminder that the tools we build shape folks lives in real, profound ways.
Building and towns are defined best not by the materials they are constructed from, or the building codes that regulate them, but rather by the events that occur within. This is further developed into the idea of spaces which are either alive or dead. Living spaces fit naturally with their defining events and dead spaces force events unnaturally.
A living space might be a courtyard between the street and the front door, a space that you would cross naturally many times over a given day, making it feel lived in and familiar: a space you incorporate into living. A dead space might be a gorgeous dead end, a room or area you occasionally remember you have, but only visit after manufacturing a reason: a space that naturally decays into disuse.
Reading this idea, what resonated with me most is that living spaces are typically defined by events that actually happen, and dead spaces are designed for events that folks hope or fear may take place, but rarely do. In the later category, it reminded me of how the ever present threat of gun violence in the United States has increasingly deadened our churches and our schools, with fear gradually coercing them into fortresses. A similar fear after the September 11th attacks rendered our airports dead. Can spaces be livable in an atmosphere of fear?
There is no equivalency between elementary school students practicing live shooter drills and brittle software development design, but there too I find that fear-driven prevention of rarely occurring events often leads to platforms, libraries and tools that are more focused on limiting their users than enabling them. We'll get to living software through thoughtful interface design and approaches like layering policy to avoid hard coding constraints.
So many patterns have shifted in my short life: the reduced role of "land line" telephones, tourism in foreign countries occurring through internet enabled navigation instead of signage or printed books, the reduced role of churches as a central community, electric heating over fire places, air conditioning coaxing folks off the front porch. (This reminding me a bit of Bowling Alone.)
If buildings are defined by the events that happen within, how do we account for the rapidly changing patterns created by the evolution of technology? Are buildings sort-of doomed to rapidly become dead as our habits shift?
I didn't quite understand the book's response to this issue, or even if it really addressed the transience of defining patterns. For many things, folks will organically fix them if the mismatch is small enough, so generally living buildings will self-correct minor things.
Bigger things? Perhaps you'll have to modify them.
More generally, I've been thinking about this theme of known unknowns, with the rate of change for doing business online internationally accelerating rather than slowing over time. GDPR requirements are one good example from earlier this year, but there are many other data locality regulations being considered across the globe's countries. This acceleration will increasingly mean that companies that want to work internationally, or honestly even nationally, will have to design for evolutionary architectures and policies that can adapt as the regulations shifts around them every six to twelve months in unpredictable ways.
The good news is that software architecture is much more changeable than physical architecture, but the bad news is that generally we're not terribly good at it, and the rate of change is much, much higher.
Even the most complicated, sophisticated things are defined by a small number of composable patterns. Cities are defined by transit, property values by school districts, and towns by main streets. The immense complexity of large cities can be predicted by these rules, and these rules can generate an infinite variety of recognizable cities.
In the context of reduced durability due to technological change, it's less clear to me whether this concept of composability matters. Yes, we can define the fundamental rules that generate our worlds, but discerning them requires careful observation and the rules themselves are evolving rapidly. More challenging still, the current status quo is not the result of the current rules, but a shifting morass of rules that are rapidly changing underneath.
I rejoice in rules, but this idea simply doesn't resonate for me.
Something that turned me off was this book's emphasis on quality being a mystical characteristic that requires secret knowledge to understand. As the references to "the quality without a name" built, I wondered if I had accidentally switched to reading the Tao Te Ching.
This kind of appeal to mystic wisdom resonated a great deal to a younger me, where my willingness to self-categorize as someone who "got it" was empowering, but I've grown warier of such things. Lately, I look at this pattern as industry gatekeeping of a particularly damaging sort: selecting for arrogance over awareness, and for confidence over competence.
I think that we, as practitioners, have an obligation to make entry into our fields accessible and attainable to as many folks as possible, and that we curse ourselves to an impoverished and impoverishing field if we narrow it to folks with enough ego and resources to self-nominate against a pervasive pressure to opt-out in self-doubt. This is, in my opinion, the book's chief failure, and one I hope I can avoid repeating.
Altogether, quite glad that I read The Timeless Way Of Building, and it's a book that will shape my thinking going forward, but still easily displaced by A Philosophy of Software Design as the most interesting (and quite readable) book I read this year.