“Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it in the same way twice.” A Pattern Language (Christopher Alexander, et al., 1977)

Architect Christopher Alexander is one of the crazy ones. The misfits. The rebels. The troublemakers. You know, he “thinks different.”

In the 1970s, he conceived and co-wrote A Pattern Language, a strange and endlessly interesting book that proposes to describe a grammar of design for the built environment based on archetypal patterns that have worked successfully in the past, can be observed in the world, and be reused and recombined in endless variety to create new designs.  The book also lovingly documents 253 of these patterns ranging in scale from regions and towns to houses, rooms, furnishings, and even ornaments, and with names like Industrial Ribbon, Corner Grocery, A Place to Wait, and Children’s Realm. Just read it.

Although madly theoretical and the author of many other books, Alexander has also put his ideas into practice in many real-world design and construction projects, some of them designed and built by the actual end users. But as his Wikipedia entry says, “Alexander is widely considered to occupy a place outside the discipline, the discourse, and the practice of Architecture.” Like Jane Jacobs or Buckminster Fuller, he goes against the grain of contemporary design and planning, or simply lives out on his own planet.

Where Alexander has been most fully embraced is in the software development community. If you Google “Design Patterns” you’ll find many links about software design and not much about architecture and construction (the brick and mortar type, that is). The prophet in his own homeland and all that, you know?

A friend recently loaned me his copy of Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson, and Vlissides (also known as the “Gang of Four”), an influential book written way back in 1994, an eternity in the technology world. Instead of Accessible Green or Farmhouse Kitchen, this work describes patterns of software engineering like Factory Method, Facade, Observer, and many more. Unlike A Pattern Language, this isn’t an easy book to read, but the introduction, where the Gang of Four define their methodology for describing and documenting patterns is worth it even if you’re not interested in software. And right from the introduction, the authors pay homage to Alexander as their inspiration.

So let’s talk about patterns. What makes a pattern a pattern and how can they help me? What was it that got the software folks excited and made this “meme” jump contexts and become so vital?

• Patterns are about NOT starting from scratch. In other words, don’t reinvent the wheel unless you have to. How amazingly pragmatic! They enable you to frame a problem and even to understand it better by trying on different design patterns– and different combinations of patterns– for size.
• Patterns are repeatable, reusable, and re-combinable. Just like words and language, you can use a pattern “a million times over, without ever doing it in the same way twice.” And by the way, patterns don’t stifle creativity for designers any more than words stifle creativity for poets.
• Patterns are flexible. They provide a template for a solution but “in a very general and abstract way, so that you can solve the problem for yourself in your own way, by adapting it to your preferences, and the local conditions at the place where you are making it.”  They are somewhere between specific and vague, between tyrannical and wishy-washy.
• Patterns are well documented. The Gang of Four point out that just NAMING a pattern is an enormous step in enabling us to talk about it. But patterns for your problem domain should also have a consistent taxonomy and structure. In other words, you specify the same information in the same form for each pattern: what problems they resolve, what patterns they relate to, and so on. This makes them understandable and interoperable. Imagine that. We can learn from each other!
• Patterns are alive and evolving. We all contribute to them and they improve, expand, break apart, and recombine. New patterns emerge. “Each pattern may be looked upon as a hypothesis.”
• Patterns are not isolated entities. Problems tend to be solved by combinations of several or many patterns. And patterns exist in relation to and interact other patterns, just like a building interacts with a street. You can’t design in a vacuum and ignore these interactions (or call them “unintended consequences”).
• Patterns are about resolving “conflicting forces”– light and shade, loud and quiet, and so on. Isn’t that what most design is?
• Patterns have some metaphor or poetry in them, both in the way they are named and described and in the way they are combined and fused into a unique solution bigger than the sum of its parts, like words in a poem. The gist of Alexander’s architectural design is human centered. And humans think best in images and stories.

Funny that software developers could learn so much from an architect. Perhaps we too should keep an open mind to viral ideas from outside our usual well-worn routines.

For example, I think of the world of business management. How many of us have learned one management pattern (usually by the seat of our pants) and clung tenaciously to it through every situation? How many business pundits do you encounter who seem so sure of their paradigm and of the rightness of their solution? It can be this and only this!

Consider a more subtle, nuanced, flexible, and evolving approach to your business problems. For that’s one final takeaway from the patterns movement: There is no one right answer.