Something missing? Suggest a change or addition

About patterns

“Once is chance, twice is a coincidence, three times is a pattern”

Put simply, a pattern describes a reusable, proven solution to a commonly occurring problem.

People who create similar systems, independently of each other, are likely to encounter similar problems. Systems continue to evolve as solutions are found that create better outcomes for the project or users. A pattern exists when we see the same solution to the same problem in different places. The fact that several people have used the same solution suggests we can be more confident that it will work in other systems, and so may help us solve the same problem elsewhere.

Patterns are carefully named, so that it is easy to refer to them in documentation and conversation. This means patterns also help us to create a shared language for communicating insight and experience about problems and their solutions.

In systems that are developed for creating and maintaining collaborative datasets, we find many different patterns. For example, we see similar ways of encouraging good quality contributions from others; in the workflow for reviewing and accepting suggestions; or in ways of maintaining relationships with the many communities involved.

Explaining a pattern to someone, so that they can benefit from other people’s experience, is not as simple as it may appear: there are many things the person must understand before they can decide whether a pattern is appropriate to their own situation or context. In addition, they may only be in the early stages of developing a system and want to anticipate whether they will encounter a particular problem in a given context.

“A pattern is a named nugget of insight that conveys the essence of a proven solution to a recurring problem within a certain context amidst competing concerns or ‘forces’”

A problem occurs within a certain context, and in the presence of competing concerns, or ‘forces’, that explain why the solution is needed. These concerns give substance to the problem, and insight into what is behind the symptoms, so that another system developer can determine whether they are operating under the same conditions. The pattern needs to reveal those forces in the description of the pattern, and describe how the solution will solve the problem, giving examples to illustrate the solution in action. The pattern is given a name which captures the essence of the solution, and can be used when discussing the pattern in other contexts.

The formation of “patterns’ and how to write them have an interesting history. If you would like to know more, check these resources.

Something missing? Suggest a change or addition