Patternity Test

PatternityTests are the various tests or criteria we employ to help us determine if something is a pattern. Ideally, PatternityTests should help you decide if the pattern form is appropriate for attempting to describe some nifty strategy or technique.

Pattern Practices

PatternityTests for pattern practices may be used to determine if some practice or strategy is indeed a pattern. The practice might not be formally described just yet, and these tests can help you decide if the pattern form is appropriate for describing it.

Some patternity-tests for determining if a thing might or might not be a pattern are:

ProvenPractice:: It is tried and true, time-tested and battle-proven practice that has been UsedThreeTimes at least (see RuleOfThree). Ideally these known uses can be cited in the pattern description (stories work well for known uses).
Geometry/Structure:: It should be concerned with some kind of structure that can be visually depicted. Alexander writes "If you can't draw a picture of it, it's not a pattern."
Forces:: It must have forces, concerns, goals, constraints, trade-offs, etc. If there is an AbsenceOfForces, many feel it's not a pattern because ChristopherAlexander explains how patterns are really a structure that results in the desired ConstellationOfForces. The "geometry" of the forces relates to the "geometry" of the solution structure. See also ForcesFromFailedSolutions, ForceContextDuality, and ForcesVsConsequences.
ForcesCreateTension?:: Furthermore, the forces must not only be present, but there should be some kind of tension, contention, or competition among them. If all the forces point to the exact same solution, then it's probably a no-brainer rather than something that resolves some kind of tension or imbalance of forces and tradeoffs. A good pattern yields a cathartic sigh of relief when the tension of the forces is pleasingly balanced or resolved (see ForcesVsConsequences)
Concreteness:: It should solve a concrete problem in a concrete context. A pattern does some amount of abstracting its solution, but if it becomes too abstract or generic, it becomes too difficult to recognize the problem or context in which the solution can be applied (or how it can be applied to the specific context)
Generative:: It should show the reader how to create something and what is to be created. It's not enough to say what to attempt to do, it needs to show how to do it and what the result should look like. See also GenerativePattern.
ProcessAndaThing:: This is essentially concreteness and generativity. A pattern is both a process for creating a thing that exists in the domain, as well as a thing that is the result of applying this process.
Enhances Quality of Life:: A pattern solution needs to demonstrate how/why it is desirable. It should show how it adds value to the architecture and/or to the lives of its users and practitioners and developers.
UsefulUsableUsed:: It must be a useful fit (enhancing quality of life), it must be fit for use (concrete and readily usable to developers and practitioners), and it must have already been used (ProvenPractice).
PeerValidation?:: If something is a genuinely recurring practice employed by expert practitioners, then one's practicing expert peers should be able to validate it as such. Find several people you know that are very knowledgeable about the problem domain and ask if they recognize the basic form of the solution you have in mind. If most of them do not, you may need to find some more abundant or convincing examples of ProvenPractice before you can call it a pattern.

The above PatternityTests are of the pass/fail variety. If the thing you are testing fails any one of those tests, it's highly unlikely that thing is a pattern. It may be something else which is still very good and very useful, just not necessarily a pattern. (See WhyPatternsAreDifferent.)

Pattern Descriptions

A pattern description is the written (literary) description of the context, problem, forces, solution, and resolution of a pattern. Sometimes even when you have a bona-fide pattern, if the description is lacking, you will be unable to convince your readers of the pattern's legitimacy.

Unlike the PatternityTests for pattern practices, PatternityTests for pattern descriptions require that the thing being tested is already described in one of the various PatternForms.

PatternityTests for pattern descriptions may not necessarily prove that the described practice is indeed a pattern. They give a good indication of how well the description persuades readers of its patternity. If a pattern description fails one of these tests, then either it is not a pattern (in which case try the PatternityTests for pattern practices), or else it really is a pattern, but the description is lacking somehow and must be remedied.

Some PatternityTests for pattern descriptions are:

PeerReview:: A pattern description should undergo some kind of PeerReview, ideally in a WritersWorkshop at a PlopConference. Patterns which have been reviewed by the community are more likely to be recognized than patterns which appear from nowhere in books on bookstore shelves. Note that Alexander's patterns were developed by a group of seven people over five years.
ConvincingRationale?:: A pattern description should ConstructConvincingArguments explaining how the solution it describes will solve the problem it addresses. It should explain how/why the solution really does resolve the problem, and how/why this particular resolution is good. The former means demonstrating the results of the solution are what you claim they are; the latter means demonstrating that this result is a good one.

For tests that WikiReaders personally use, see PersonalPatternityTests.

I recently reread Alexander's TheTimelessWayOfBuilding, and found his discussion of what is a pattern, and how to construct one, highly enlightening on the matter. Best I can say is, read that. -- AlistairCockburn

Okay, so there's no rabbit involved in all this, right?