Pattern Development has an Ethical Telos. The discipline has clarified Alexander's "quality without a name" so that it now talks about quality of life. Neis calls it "the improvement of life, human development and improvement of the environment in which we live." This means that pattern theory understands what it is doing as an ethical act and has gone so far as to recommend the ethical principle that should be followed. As I consider how to do a theology pattern language, this asks what my ethical principle is.
Patterns Exist for Solutions. Neis expands on the term pattern and calls it a problem-solution pattern, and he is clear that solving problems is the point. "A pattern is . . . a rule which addresses a clear problem which may occur repeatedly in the environment, states the range of contexts in which this problem will occur, and gives the general features required [to] solve this problem." A pattern is like a hypothesis which is stated with evidence pro or con. It is a system based primarily on functional considerations. The principle of patterns lays out of way of tackling problems that invite dialog. Patterns are formulated as archetypal, general solutions that can find endless forms of specific solutions and applications according to context and interpretation." Patterns should be as clear as possible in order to promote understanding and invite dialog. In this sense, they are a way of scientifically encoding a discipline--I keep thinking of the dialogic system of Thomas Aquinas's great summas.
Connections make a language. Nais confirms what I expected. The language part of a pattern language emerges as patterns are connected to general and to specific patterns around them. A pattern begins by listing off related patterns at a higher level from it, and it ends by listing patterns at a lower level. This democratizes expertise and "provides users an organized procedure to help make sense out of otherwise complex situations." Patterns provide shared grammar. Patterns require user participation to make value; words are made for speaking.
Languages are General and Specific. Nais also confirms how pattern languages are used and how they are contextualized! "An architect . . . select[s] a set of patterns and use[s] these solution-patterns as archetypal starting points for a design and building process." Planners, he continues, will choose out a set of patterns appropriate to their need, and then--here is the innovation--they will create new patterns required for that particular project. The original pattern language Nais calls the General Pattern Language. Such pattners are a archetypal solutions. They are not contextual. The new, customized set of patterns are contextual. Neis calls these the Project Pattern Language. "Each project is different and unique in its own way and therefore needs its own Project Pattern Language as an important aspect of innovation, originality, and creativity within the larger complex system of functionality and harmony. . . . a Project Pattern Language may contain quite a few patterns in their solution or hypothesis form."
Patterns are just part of the thinking process. A pattern language (general or project) sits in a continuum of thinking that may begin in ideas, dreams, poems, and any kind of creativity. "In a project language, patterns are not the only defining elements any more, but all kinds of specific ideas, dreams, visions, may make up a coherent language for a particular project. Narratives, stories and poems could serve as starting points for a project and can serve as starting points of innovation, improvisation and creativity. . . . pattern languages do not replace design, but they are part of the design process."
Anti-patterns: the what not to do. These are proposed solutions that create more problems than they solve and therefore should be avoided. Such bad solutions are called anti-patterns. Neis doesn't go into it, but introducing a no creates a new subtlety to the overall language.
Final thoughts: Combining these insights with other posts I've accumulated on pattern writing, I understand now that simply saying a theological thing like bread, covenant, Son, or water is not making a pattern. Even thought these words may represent a nexus of theological meaning, they don't clearly solve anything. They need to be reworked with the user in mind in order to be made useful for them. Those nodes may often represent the solution to a problem, but saying the bare thing doesn't clearly help the user.
By understanding the problem-solution nature of patterns, I see now that the quality without a name that governs my system must exist on the vertical and horizontal planes simultaneously. In an earlier post, I said worship would be the telos of my system. But this is only the vertical. Recalling the service a pattern should be to a user, the telos must be to guide the user into greater degrees of worship of the triune God.
