In my last post I blathered about some similarities between software and fiction. Or something. If you made it through to the end you may have noticed I promised I’d come to some kind of practical conclusion.
I believe there is one approach to gathering and sharing knowledge that has worked well in other fields, including software, that could be useful for fiction writers. This is the pattern catalog.
The concept of a pattern language was developed by Christopher Alexander in relation to architecture.
“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 the same way twice.”
A Pattern Language (Oxford University Press, 1977)
A pattern, then, is first a problem defined, and then a potential solution. This order of precedence is important. Patterns begin with an understanding of challenges and requirements. Solutions flow from that basis. It’s not enough to know how to build an archway, for example, you need to know why an archway is right for particular set of conditions in a courtyard.
Patterns are named and collected in catalogs. They tend to work together. A pattern defines a problem, suggests a solution, which creates conditions that might form the problem for other patterns in the same catalog.
So here are some of the characteristics of a pattern:
Name
A pattern is named. This is important, because the name becomes the shorthand for both the solution and the problem. When a pattern language works well it creates a vocabulary that can be shared among practitioners of a craft. New techniques can quickly be added to the toolbox, and then shared in the context of other named patterns. “What you need there is a doodad. That’ll fit in neatly with the whizzbang you’re using over here.”
Problem/summary
Patterns are all about context. The most memorable thing about a pattern is generally the solution. A neat solution is a fine thing after all. But you need to know what works in which situation and why. Patterns begin with the problem space. A problem should be described briefly, and then contextualized with examples. When someone flicks through a pattern catalog, he or she is hunting for problems that match a particular need in his/her project. Patterns, therefore, are organized and summarized by the objectives they satisfy.
Solution
This is the sexy bit, the what-you-do part. A solution should be general enough that it might be applied in quite different ways. Martin Fowler, writing about software patterns, said that solutions should be ‘half-baked’. By this he meant that they should not be so finished that they only work in a narrow context. A solution should be rendered in principle, so that it can apply across a range of situations. If a pattern in a cookery catalog concerned sauces, for example, it would describe a general practice that responds to a problem. Thickening, or thinning, or rescuing a sauce. It would not be a recipe for bolognese sauce.
Worked example
Some people like to work from a principle and find their own way to an instance. Others prefer to work from observation to theory. A pattern can often accommodate either preferences. A simple example of the solution in action, serves to clarify. Here’s where you might find your bolognese recipe, but only if it precisely demonstrated the general principle of sauce preparation described in the solution. Notes would clarify the relationship between the example and the principles it illustrates.
**
Consequences**
Every action has them. Fiction writers take full advantage of this, of course. A pattern describes a problem and its solution. Then it must describe the implications of that solution. This is important because unintended consquences can be worse than your initial problem. Much worse. A pattern should prepare its potential users for as many outcomes as possible. Luckily outcomes, often prompt new patterns.
**
Related Patterns**
Patterns imply patterns. Because a pattern has consequences, and a consequence is a new context, there are often new patterns to match. This section mentions them by name, and suggests how they might help.
Real examples
For a pattern to be valid, it should be observable in the wild. This is important because patterns are not inventions. They describe real practices developed and applied by masters. Patterns should be already proven. Only then are they are they codified to save everyone else from having to work them out all over again.
Examples perform two roles. First they again help clarify a solution by showing it applied. Second they demonstrate that the pattern itself is valid. Some hold that a pattern must be validated according to a rule of three. Without three real world examples, you don’t yet have a pattern.
So might this model apply well to fiction? Could we build up a repository of named, interrelating fiction patterns? Maybe there’s already one out there? TV Tropes comes close and should certainly be cross referenced by a fiction pattern language. I’ve come across a number of books the read very like pattern catalogs too (I need to look these out when my books come out of storage eventually).
In any case I think the pattern structure makes a good template for posts, and a great tool for analyzing craft, and later retrieving and using what you have learned. In my next article on this topic I’ll create an example pattern.
