Thursday, September 10, 2009

Christopher Alexander & Patterns

I thought these chapters were very interesting!  Over the past few days I've been looking over some of my wife's architecture books (she's an Interior Design student), and I can see more and more parallels between the two.  Initially, I had seen these parallels more in regards to building large public buildings, and the various disciplines, stakeholders, and the various forces involved.  Christopher Alexander has made me see how architecture and patterns relate to a much wider range of situations.

A pattern language, either in software or in physical architecture, provides a mechanism for describing a facet of design, it's purpose, uses, strengths, motivations, applications, and implementation.  Pattern languages help break down tasks (once again, in either physical or software architecture), and provide templated building blocks, which which the designer can go about building a system/structure with proven quality attributes.  Alexander stresses that these pattern languages can help designers match context, function, and form of various facets to the overall whole, and provides a framework for organic growth, wherein a pattern doesn't provide a restriction, but rather a pathway of inquiry.

I think that physical architecture patterns differ from software patterns in that they are more immutable than software patterns.  Whereas physical architecture is subject to the laws of physics--statics, optics, etc., software is subjected to ever changing set of fundamental paradigms.  Though ideas come in and out of vogue in both fields, I think that software patterns have to be more flexible and complex, because even though the author talks about buildings, towns, etc., coming to being through organic processes, there is still a relatively static end product--you may build a house based on patterns, but you're not that likely to start shuffling the windows around once it's built.  Software, on the other hand, is always changing, as requirements evolve, and the business environment changes, software is expected to evolve gracefully to meet such needs.  This differs from the evolution of a town in that whereas in a town, you may build new things to meet current needs while being contextually relevant, you don't undertake as sweeping changes with a town as you might with a software system--you don't talk about lifting up a whole town, and placing it on a more modern sub-grade--whereas with software, upgrading the platform and paradigms is an ongoing challenge and requirement.

I think that (physical) architectural patterns are timeless to the extent that physics and basic human nature is immutable.  Some patterns which relate to the current state of technology or lifestyle (such as barns), not so much.  I think that even in software patterns, there are some elements of timelessness, perhaps not in the exact wording and digital world-view that was prevalent at the time of writing, but in the fundamental decomposition of ideas and intentions, certain aspects of software patterns, too, will live forever.

No comments:

Post a Comment