Let's Recommon IT

Patterns Are Tested in Practice

A pattern is a claim until someone uses it.

Thread:
Design patterns
Level:
metaconstitutional, in the theory column
File:
wiki/patterns/patterns-are-tested-in-practice.md

draft

explained in A pattern language for community tech

Patterns Are Tested in Practice Sketch in perspective: a stove with a pot on it, steam rising. One mannequin stands at the stove tasting from the pot with a spoon. A second mannequin stands nearby holding up a hatched recipe card and writing a correction on it with a pencil. The recipe card is a pattern, the focus. The stove and pot are practice: a real place where the pattern gets used. Cooking from the card and tasting the result is the first half of the solution: apply the pattern somewhere besides where it was written. Writing on the card is the second half: when the pattern doesn't fit what happens in practice, revise it and say why. The two figures are different people, so the test isn't only by the pattern's author. The metaphor: a pattern as a recipe, which proves itself only when it's cooked, and gets corrected in the margins.
Fig. 6

A pattern is a claim until someone uses it.

Context

A pattern language that grows out of essays, guides, and reading, as this one does.

Problem

Patterns that come only from argument drift toward abstraction. They sound right, but nobody has checked whether they work, and over time the language fills with good intentions instead of tested solutions.

Forces

  • Alexander’s design method starts from fit: what actually goes wrong in real use (Notes on the Synthesis of Form). His patterns came from observing places that worked and places that failed (The Timeless Way of Building).
  • Iba’s lab mines patterns from experience, through group reflection and interviews with practitioners (Iba, “Pattern Language 3.0”).
  • Writing from reading is faster than writing from practice, and an essay rewards a pattern that sounds right.

Solution

Therefore, apply every pattern by name in at least one piece besides the one that introduces it, preferably at another level or in another thread, and revise the pattern when it doesn’t fit.

Actions

  • List each applying piece in the pattern’s applied_in.
  • When a pattern doesn’t fit, revise it and say why in the commit message.
  • Mine patterns from your own experience or from interviews, not only from reading.

Consequences

  • Positive: the language fills with solutions that have met real servers and real groups, and failures improve the patterns.
  • Negative: a new pattern waits for a second piece before it counts as tested, and a pattern applied only by its own author is still lightly tested.

Mark up this page on GitHub