What is the difference between a Pattern, a Principle, a Heuristic, and a Best Practice (or good practice)?

Pattern Language
1

I’ve been thinking a bit on this question recently, as I see these terms sometimes used borderline interchangeably in the literature.

For example, I have come across the notion of ‘design patterns’ as used in scenarios that are perceived as complex, with these patterns meant for replication/transferability, meanwhile most of us here have probably at least glanced at Jones (2014) ‘Systemic Design Principles for Complex Systems.’ This isn’t to say that a design pattern as used above necessarily relates strongly to Pattern Language, except that the author of that text cites the use of the term in respect to Alexander.

I’m also aware that somewhere, I read that patterns as typically conceived are not best applied to complex systems or wicked problems, as they are so often context dependent.

As @daviding has pointed out several times prior, Alexander titled the work with the article A, as in A Pattern Language, not The Pattern Language. Again, we see a consideration for replicability.

Probably, the genealogy of terms used is what differentiates here, but I’m curious if anyone has put the time into a set of functional definitions. I can see how a best practice could shift to a ‘good practice’ depending on context.

In searching on this topic, I found this interesting take on the difference, which views Patterns as complementary to, but not substitutable with, heuristics and principles:

A pattern language can be defined as a structured method for describing good design practices within a field of expertise. Patterns are different from other forms of catching design knowledge, as guidelines or heuristics, in three ways. First, patterns offer a solution to concrete problem rather
than providing abstract suggestions. Second, patterns are creative, helping designers,
architects and engineers to generate a new solution by presenting several examples of
the same problem. And third, patterns are connected between them by a hierarchical
structure, so designers can resolve both complex and simple problems. Patterns are
not going to replace guidelines or heuristics; patterns are a good complement for
them.

Does anyone here have some thoughts on this relationship?

2

Asking for definitions, @Gryph, is a slippery slope. My preferred sources for insight into meaning is:

Rather than providing specific entries that might be otherwise looked up, let me provide distinctions that I use myself.

The word pattern is rarely helpful in itself, and needs (at least) a modifier to be really useful.

The term pattern language is clearly Alexandrian, as Christopher Alexander (with coauthors including Max Jacobson) having published the original book in 1977. The language shouldn’t be seen as isolated patterns, but patterns amongst and in combination with other patterns. Denying the context around a pattern creates a universal that is counter to the idea of a pattern language.

Alexander et al. (1977) provides a description.

The elements of this language are entities called patterns. 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 (p. x).

Those following an Alexandrian approach want to ensure problems and solutions which occur “over and over again”. Noticing something once isn’t worth recording as an Alexandrian pattern.

A conventional way of describing an Alexandrian pattern is as “a solution to a problem in context”.

The term “design patterns” was associated with the Gamma, Helm, Johnson, Vlissides (1995) book. Speaking with Ralph Johnson at the 2014 PLoP conference, the publishing of the 1995 book was done completely independently of the Alexandrian-based PLoP 1994 meeting. The PLoP community has done crossover work to blend ideas, but the *Design Patterns" book is not considered to be Alexandrian.

For principle, let’s borrow some of the entries from the OED.

principle, n.
I. Origin, source; source of action.
II. Fundamental truth or law; motive force.
III. Rudiment, element.

Compared to an Alexandrian pattern, there’s no solution-to-a-problem-in-context sense in a principle.

For heuristics, let’s also refer to the OED.

heuristic, n. and adj.
A. n.
2. A heuristic process or method for problem-solving, decision-making, or discovery; a rule or piece of information used in such a process.

Compared to an Alexandrian pattern that explicitly requires a context, a heuristic only mentions problem-solving (although common sense would suggest contexts in which the heuristic would be unhelpful).

I personally didn’t seem best practice come up as a popular term until the 1980s, but suspect that we can look back into industrial engineering. Looking at *The Psychology of Management" (1921) by efficiency expert L. M. Gilbreth (whom I remember from Cheaper by the Dozen), we see

CHAPTER VI
STANDARDIZATION
Standards Derived from Actual Practice. — Management derives its standards not from theories as to best methods, but from scientific study of actual practice. 2 As already shown, the method of deriving a standard is —

  1. to analyze the best practice known into the smallest possible elements,
  2. to measure these elements,
  3. to adopt the least wasteful elements as standard elements,
  4. to synthesize the necessary standard elements into the standard.

Standardization in constructing built environments such as houses and towns is counter to the ideas coming from Christopher Alexander in *The Timeless Way of Building" (1979). This is much better illustrated in *The Battle for Life and Beauty on the Earth" (2012), where it’s clear that Alexander prescribed creating a new pattern language in designing the Eishin School, not reusing fragments from the old pattern languages on other works.

The idea of a project language, as a subset of a larger pattern language, would formally be published much later:

Motohashi, Masanari, Eiiti Hanyuda, and Hiroshi Nakano. 2013. “From Pattern Languages to a Project Language: A Shift Proposal from Existing Pattern Community.” In Proceedings of the 20th Conference on Pattern Languages of Programs, 33. The Hillside Group. http://dl.acm.org/citation.cfm?id=2725669.2725708, cached at https://hillside.net/plop/2013/papers/proceedings/papers/motohashi.pdf .

1 Like