Writing New AntiPatterns

There are several key observations that will aid in your future work on patterns and AntiPatterns:


1. Design patterns start with a recurring solution. Design patterns are usually written from the bottom up; in other words, design patterns start with a recurring solution. The pattern author later adds context and forces. These context and forces are carefully crafted to lead you to a unique solution; the solution they started with. This explains why many design patterns are hard to read. As a design pattern reader, your first task is to decipher the logic behind the context and forces. Often, this logic leads you to one predetermined conclusion, rather than a real understanding of the forces, symptoms, and consequences of the real situation. The solution often seems obvious and simple, especially after the detailed, in-depth examination. AntiPatterns are an attempt to discuss the material appropriate for design patterns in a form much more palatable to the reader.


2. AntiPatterns start with a recurring problem. AntiPatterns are written from the top down. The AntiPattern starts with a commonly recurring design or practice. In typical, current context, the design or practice has obvious negative consequences. Select one or more pejorative names to identify the AntiPattern; the best names are those in popular use. The AntiPattern description includes learning elements such as symptoms, consequences, and causes. We choose to list symptoms and consequences together. Symptoms are in the past and present; consequences are in the future. Separating symptoms and consequences would establish a time frame for the state of the AntiPattern.


3. Use study groups. It is useful to discuss a written description of the AntiPattern and its refactored solution in a group environment; writer’s workshops are one form. We have also found that less formal discussion groups made up of software peers, like book study clubs, are effective forums. The group can tell you whether the write-up is really an AntiPattern by recalling instances of the AntiPattern’s occurrence.


From our experience reviewing many design patterns and AntiPatterns in group situations, we find AntiPatterns much more fun! (than ordinary patterns) A good AntiPattern gets people involved in the discussion. Good AntiPatterns tend to inspire people to contribute their experiences and ideas.


4. Become an AntiPattern author. New AntiPattern authors can focus on recurring problems that are observed in several distinct contexts (at least three, similar to the rationale for describing software design patterns). To fully describe an AntiPattern, it’s important to supplement the AntiPattern problem description and solution with a discussion of causes, symptoms, and one or more concrete examples to provide a clear context. In the solution, one of the examples should discuss the successful refactoring of a situation that uses the guidance given in the solution. This does not necessarily have to be from a current project, but it can relate to experience on other projects and in other companies, even when there was no direct involvement. The refactored solution does not have to be a unique solution, but it should be highly relevant.