Patterns and Antipatterns

Alexander is an architect and professor emeritus of the University of California, Berkeley who realized that many medieval cities possessed a certain harmony and elegance and that, indeed, "There is one timeless way of building. It is a thousand years old and the same today as it has ever been. The great traditional buildings of the past, the villages and tents and temples in which man feels at home, have always been made by people who were very close to the center of this way. It is not possible to make great buildings, or great towns, beautiful places, places where you feel yourself, places where you feel alive, except by following this way. And, as you will see, this way will lead anyone who looks for it to buildings which are themselves as ancient in their form, as the trees and hills, and as our faces are" (Alexander et al., 1975).

In their trilogy of books, Alexander et al. (1975, 1977, 1979) explore the idea that successful architecture is essentially the application of design patterns that have been around for thousands of years, albeit not recorded. They attempted to record them and to the layperson they certainly feel right. An example is the Four-Story Limit pattern:

Of course, this is not a book about architecture and town planning. The point we are making is that a previously undocumented rule or principle has been documented in such a way that future architects can easily identify with and apply it in their work. This, essentially, defines the concept of a pattern.

1.2 Pattern Structure

The most obvious aspect from the Four-Story Limit pattern, and Craig Larman's definition for patterns, is that each pattern has a useful name. It conveys, in a terse and compact manner, the pattern's intent. In fact, the choice of name is very important because the set of patterns on a given topic actually form a vocabulary of communication ... a language, hence Alexander's book title, A Pattern Language.

These languages allow for groups to communicate broad ideas and complex solutions to problems very effectively. Rather than having to explain intricate details of a problem or the rationale for a solution, groups just use the pattern names they are using and everyone has a clear picture of the work at hand.

The next section is the conflict. This summarizes the problem the pattern addresses. In the full version of the pattern, this summary is followed by more details explaining the problem, its manifestations, and relevant background or context.

The final section in this pattern language is the solution. This succinctly explains the solution to the stated problem. The important aspect here is that the solution is in general terms, not a specific answer. Patterns describe solutions to recurring problems in a way that each individual solution is different, yet still conformant to the patterns' rationale and intent. For example, Alexander's architectural patterns describe appropriate scale, layout, and use of buildings, parks, and walkways, but the communities designed using them are not identical to one another.

This is just one format for patterns, however, and relative to other pattern languages would be considered a minimalist structure. In addition to the name, conflict (or problem), and resolution (or solution), more expansive formats include sections that describe the consequences of using the pattern, both positive and negative; implementation details that provide more detail in applying the pattern; and the scale or scope of problem the pattern addresses.

1.3 Antipatterns

While it is certainly useful to study the successful ways people solve problems, the old adage that we learn from our mistakes suggests that studying failures might be even more fruitful. This is the concept behind negative patterns, or antipatterns. Whereas patterns describe a recurring problem and its solution, antipatterns describe solutions that have more negative consequences than positive benefits.

In effect, they describe dysfunctional approaches to problem-solving, followed by the changes that should be made to overcome this dysfunction. That is, antipatterns describe situations that we often find ourselves in, situations that are not healthy for the individual or the organization. We obviously do not set out to create these dysfunctional situations; they occur because of neglect, malice, ignorance, and assorted other reasons. Once in these predicaments, how do we get out and stay out? This is the rationale for antipatterns in general, and our catalog in particular.

The idea of antipatterns emerged soon after that of patterns, but it is unclear who first coined the term. In 1995 Andrew Koenig published a short article in the Journal of Object-Oriented Programming using the term, and in 1996 Michael Akroyd presented a paper at the Object World West Conference that documented harmful software constructs. We will happily give credit to both. Credit for promoting the term, however, must go to the authors of the antipatterns book by Brown et al. (1998). They expanded the scope of antipatterns to include software project management as well, arriving at a three-pronged taxonomy of antipatterns: architectural, design, and management (Table 1.1).

We have further expanded the scope of antipatterns to include broader management and leadership aspects, as well as introducing another kind of antipattern, the cultural or environmental antipattern. These are dysfunctions that are not attributable to a single person, situation, or practice. Instead, they are due to a series of "solutions" or environmental changes that create a toxic atmosphere-a negative organizational culture.

1.4 Many Eyes

We have not merely sat in a darkened room and created these antipatterns in a vacuum, however. An important aspect of patterns and antipatterns is the "rule-of-three," and we have abided by it. To call a pattern a pattern, it must have been used successfully in practice three times; to call an antipattern an antipattern, it must have been witnessed three times. In most cases, we have personally witnessed each pattern on at least three occasions, in different organizations, in different industries, and often in different countries.

In addition, more than 100 IT professionals have validated the antipattern catalog, and it has been reviewed by several CEOs, CIOs, CTOs, and assorted other senior executives and managers from a wide range of industries, including aerospace, construction, manufacturing, finance, and consultancy. We are confident that every reader will see themselves, their peers, supervisors, subordinates, and companies within the catalog, and hopefully by the end of the book they will be empowered to stride forward as agents of change.

1.5 Antipattern Structure

As with patterns, antipatterns form languages, so they must have unique and meaningful names. This seems to be the only firm structural requirement, however. Brown et al. adopted a comprehensive format, including:

• Antipattern name and AKA (Also Known As)
• Keywords (relating to their antipattern reference model)
• Background
• Anecdotal evidence
• Antipattern solution (general form)
• Symptoms and consequences
• Typical causes
• Refactored solution
• Variations
• Example
• Related solutions

Our antipatterns have a less formal structure, however, one that concentrates on identification of the dysfunctional situation and remedies for all those involved:

• Name: a name that conveys the antipattern's meaning.
• Central Concept: a short synopsis of the antipattern, enough to make the antipattern identifiable.
• Dysfunction: in general terms, the problems with current practice, possibly with a list of symptoms.

1.6 Management and Environmental Antipatterns

The antipatterns language cataloged in this book is divided into two broad types:

1. Management. These are caused by an individual manager or management team ("the management"). These antipatterns address issues in supervisors who lack the talent or temperament to lead a group, department, or organization.
2. Environmental. These are caused by a prevailing culture or social model. These antipatterns are the result of misguided corporate strategy or uncontrolled socio-political forces.

1.6.1 Antipattern Locator
Because we have adopted a simplified classification structure for our language, we have identified major foci for each antipattern so that users of the language can quickly identify which antipatterns are at work in their organization. The complete list of antipattern foci is as follows:

To find the antipatterns affecting you, identify which of the characteristics from the list best captures the type of problems you are experiencing. Trace down from each identified characteristic in Tables 1.2 and 1.3 to find the possible antipatterns that match your situation.

For example, if you believe that your organization suffers from a general lack of courage and honesty, then you may wish to explore the Emperor's New Clothes antipattern. If the problem is due to an individual manager's lack of honesty and competence, then you might wish to explore Fruitless Hoops or Metric Abuse as the antipattern. Knowing ahead of time if the problem is related to a dysfunctional manager or culture allows you to narrow your search to either Table 1.2 (Management Antipatterns) or Table 1.3 (Environmental Antipatterns).

Of course, many of the antipatterns have one or more influencing factors in common. For example, from Table 1.3 it can be seen that the Fairness Doctrine and Pitcairn Island manifest characteristics of dysfunctional cultures and personnel situations. Therefore, you would need to read both of these antipattern descriptions to uniquely identify your predicament.

We suggest, however, that you do not try to locate a specific antipattern by precisely identifying its unique set of influencing factors. Instead, select two or three influencing factors that clearly fit the situation; then read all of the antipatterns that match those factors.

It could also be the case that your predicament involves more than one antipattern, as they tend to exist in swarms. Reading all of the antipatterns that seem to apply will give you the broadest range of solutions, that is, refactorings.

1.7 Consistency and Completeness

The reader may be led to a very obvious question. Is this antipattern catalog complete? That is, does it describe all possible dysfunctional managers and environments? In short, we think not. However, we have spent more than seven years developing this catalog, and we think we have come rather close to completeness. We rejected a number of other candidate antipatterns for a variety of reasons; e.g., was not really an antipattern, did not meet the rule of three. But it is possible that other unique antipatterns are out there. We will be looking for them.

Finally, a word on consistency. What we mean by this is that some of these antipatterns will look very familiar to you when you read them. You just might know them by another name. For example, one of our reviewers said, "Ah, we knew about that antipattern; we used to call it '30th Street mentality' (for the site of an old office)." It is fine if you do recognize these by another name. We did not invent these dysfunctions-most of these have probably been around since the first human societies.

Our mission was to seek to concisely capture and describe these antipatterns so that a new terminology would emerge-one that transcends the local jargon of one company or another. This way, when that reviewer who noted the "30th Street mentality" moves to another company where that term has no meaning, he will be understood because now he can talk about "Institutional Mistrust."

About the Author

From Antipatterns: Managing Software Organizations and People, Second Edition by Colin J. Neill, Philip A. Laplante, and Joanna F. DeFranco. New York: Auerbach Publications, 2012.