More negative examples

A new library may help refine the form of patterns in the face of the much-needed conversion to a problem-centric record of wisdom. But we must fight the problem of abundance. We can do this by agreeing on a formal way to decide whether a pattern is new and valuable and only publish as patterns those that pass the test. However, we should still record every pattern submitted. A library is not only an excellent place to store the truth but also the right place to keep negative examples. We can use them to help others understand when they have veered off course.

Diagrams

Physical building patterns used diagrams because they related to the geometry of construction, so we deemed them necessary for the software design patterns. But it was a mistake, a misunderstanding of what diagrams were for in A Pattern Language[APL77]. Maybe no one deeply understood the reason for diagrams and so couldn’t find an equivalent representation for code because they didn’t know what they were looking for. This is almost certainly true, as Christopher Alexander and his team had yet to discover the limitations of the diagramming provided in A Pattern Language.[APL77].

The diagrams in A Pattern Language.[APL77] most often showed the final form. Even in places where the process was vital, there was no diagram of the transformation. If a pattern is meant to be a process and a thing, these diagrams only show half the picture.

What the diagrams lacked were negative examples. They would have reduced the oddness of some designs using the architectural patterns of house building. We should not replicate this mistake where the process is not shown and only the final result is revealed. We must protect readers from misunderstanding by presenting negative cases, otherwise they will end up learning to dance like children copying adults.

Proof by contradiction

Zendo is a board game involving plastic pyramids and sleuthing. It can show you the power of negative examples. In the game, you try to deduce a rule; in the same way as a pattern reader, you try to internalise the presented wisdom.

You start with the lead player showing you a pair of examples related to their selected rule. One is a positive example, the other a negative. The rule can be entirely made up and can include things such as:

  • There must be two red pieces
  • There must be a pyramid on its side
  • All pieces must be on the table
  • A piece must be touching another piece

They can have negative rules such as:

  • There must not be any blue pieces
  • No wedge shapes allowed
  • No small on top of large shapes
  • Pieces must not touch

The game involves players constructing their own examples and asking the lead player whether their creation matches the rules. It doesn’t take many turns for people to figure out even the most complicated rules, but the structures built to test negatively provide the best clues to the rules. The aim of the game, after all, isn’t to create designs that follow the rules but instead understand the rules themselves.

This game shares a lot with Cluedo™ when playing the Zendo variant using cards, but the variant where the lead player merely makes up the rule increases the possibility beyond a simple game of deduction. You must create experiments to test your hypotheses. The deeper, more free-form game shares the important aspect of the uncertainty of the boundaries of the example solutions from design patterns, descriptions, and diagrams. And both games share this trait of the unknown with the game called Petals Around the Rose.

Knowing what a street should look like doesn’t help you as much as knowing what a street should not look like. Knowing about counterexamples of building design is very helpful. Just seeing a thick wooden step to stand on, you might believe the step needs to be made of wood but not realise the thickness matters. You might not be aware of the importance of the depth and rise of the steps either. Counterexamples highlight things you need to worry about. Design patterns, being wisdom, require counterexamples to present this most crucial aspect. This negative aspect is missing from almost every pattern ever published.

The library must include negative examples to help guide to a better set of languages and patterns. So, it must include the original Singleton pattern.