Unlike design patterns, AntiPatterns focus on software failures in an attempt to understand, prevent, and recover from them. To developers, AntiPatterns are a tool that bridge the gap between architectural concepts and real-world implementations.

June 01, 1998
URL:http://drdobbs.com/architecture-and-design/antipatterns/184410581

Hays is a lead engineer at MITRE, and can be contacted at [email protected]. Raphael is chief scientist at Eidea Labs and can be reached at [email protected]. They are coauthors of AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis (John Wiley & Sons, 1998).

The emergence of the design patterns movement has gone a long way toward codifying a concise terminology for conveying sophisticated computerscience thinking. Still, the likelihood of success for practicing managers and developers is grim. According to J. Johnson in "Creating Chaos" (American Programmer, July 1995), for instance, studies of hundreds of corporate software-development projects indicate that five out of six projects are considered unsuccessful, about a third are canceled, and those remaining deliver software at typically twice the expected budget, having taken twice as long to be developed as originally planned.

While we can assume that all software was intended to solve some problem, these solutions are sometimes as bad as (or worse than) the problem they originally were intended to solve. It is these repeated failures, or negative solutions, that provide the source for the study of what we call "AntiPatterns."

AntiPatterns versus Design Patterns

Unlike design patterns, AntiPatterns start with an existing solution (or legacy approach). Most patterns assume a situation where there are few, if any, preexisting concerns that affect the design of a system. However, experience has demonstrated that situations with legacy and existing problems are much more commonplace in practice. The AntiPattern background and general form amplifies the problem in a way that helps you recognize the problematic structure, symptoms, and consequences. The AntiPattern then presents a common solution that refactors the system to improve benefits and minimize consequences.

As Erich Gamma et al. point out in Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1994), design patterns focus on a particular software-design problem or issue. They contain a detailed discussion of the forces that influence the issue. In the design-pattern solution, the forces are either resolved or an appropriate tradeoff between the forces is established. This results in a divergence-convergence pattern where the context and forces diverge from the problem to provide a greater scope, and the solution diverges by resolving the forces into a single focused solution.

AntiPatterns, on the other hand, are based on a different rhetorical structure. AntiPatterns begin with a compelling problematic solution. From this solution, as Figure 1 illustrates, a discussion of the root causes focuses how the problematic solution is the result of incorrectly resolving the forces for a specific underlying set of problems. This convergence from a concrete situation to the more abstract underlying forces is a key component in communicating an understanding of how and why the problem exists. The Symptoms section provides additional clues for recognizing the improper resolution of the key forces. In the Consequences section, the implications of the problematic solution are discussed, thus providing a divergence similar to a design-patterns discussion of context. Finally, the Refactored Solution provides a better convergence of the underlying forces that lead to a better understanding of the problem and an effective method of resolving it.

AntiPatterns are therefore a natural extension to design patterns. Rather than codifying pure computer science, AntiPatterns focus on repeated software failures in an attempt to understand, prevent, and recover from them. To developers, AntiPatterns are a tool that bridge the gap between architectural concepts and real-world implementations. They are used to illustrate the common, critical problems faced by most software developers and enable learning from other developers' experiences. Only with an understanding of the causes and motivations of an AntiPattern can you ensure that your mistakes are not continually repeated within an organization.

AntiPattern Components

The use of a template defines the difference between design patterns and AntiPatterns and other forms of technical discussion. Templates ensure that important questions are answered about each pattern in a pattern language, pattern catalog, or pattern system. The full AntiPattern template provides a wide range of information about a particular class of problems, including a discussion of the AntiPattern background, the general form, symptoms and consequences, root causes, a refactored solution, and an example detailing how the refactoring process can be applied to create an effective solution. A catalog of AntiPatterns is available electronically (see "Resource Center," page 3). For this discussion, however, we'll use an abbreviated version of a pair of AntiPatterns (the Lava Flow and Stovepipe System). The solutions include the following:

• General Form. Often including a diagram, the general form section identifies the general characteristics of this AntiPattern. This is not an example, but a generic version. A prose description explains the diagram (if any), and provides the general description of this AntiPattern. The refactored solution resolves the general AntiPattern posed by this section.
• Symptoms. Symptoms provide the observable indicators that suggest an AntiPattern might exist in a specific situation. They manifest through comments from individuals, the observed structure of software, organizational changes, the inability to meet targeted goals, and so on.
• Typical Causes. This section summarizes the key underlying causes that typically lead to the existence of a particular AntiPattern.
• Known Exceptions. AntiPattern behaviors and processes may not always be wrong. There are often specific occasions when this is the case. This section briefly identifies the primary exceptions to each full AntiPattern.
• Consequences. The Consequences section describes the harmful effects of the AntiPattern. They include the continuing damage caused by the AntiPattern as well as likely outcomes if corrective measures are not taken.
• Refactored Solution. This section explains a refactored solution that resolves the forces in the AntiPattern identified in the General Form section. (This solution is described without variations that are addressed in the Known Exceptions section.) The solution can be structured in terms of solution steps.

AntiPattern Name: Lava Flow

As Figure 2 illustrates, the Lava Flow AntiPattern is commonly found in systems that originated as research but ended up in production.

General Form

It is characterized by the lava-like "flows" of previous developmental versions strewn about the code landscape, but now hardened into a basalt-like, immovable, generally useless mass of code that no one can remember much (if anything) about. This is the result of earlier developmental phases where developers tried out several ways of accomplishing things, perhaps while in a research mode. Predictably, a deadline arises and, in the rush to deliver, sound design is cast to the winds and the documentation of the system becomes sketchy, irrelevant, or altogether nonexistent.

The result is several fragments of code -- wayward variables, classes, and procedures that are not clearly related to the overall system. In fact, these flows are often so complicated and spaghetti-like that they seem important but no one can really explain what they do or why they exist. Sometimes a developer can remember certain details, but everyone has decided to "leave well enough alone" since the code in question "doesn't really cause any harm, and might actually be critical, and we just don't have time to mess with it."

While it can be fun to dissect these flows, there is usually no time in a production schedule for such meanderings. Instead, people take the expedient route and work around them. This AntiPattern is common in innovative design shops where proof of concept or prototype code rapidly moves into production. It is poor design, for several key reasons:

• Lava Flows are expensive to analyze, verify, and test. All such effort is expended entirely in vain and is an absolute waste. In practice, verification and testing are rarely possible.
• Lava Flow code can be expensive to load into memory, wasting important resources and impacting performance.
• As with many AntiPatterns, you lose many of the inherent advantages of an object-oriented design. In this case, you lose the ability to leverage modularization and reuse without further proliferating the Lava Flow blobs.

Symptoms

• Frequent, unjustifiable variables and code fragments in the system.
• Undocumented, complex, important-looking functions, classes, or segments that don't clearly relate to the system architecture.
• Very loose "evolving" system architecture.
• Whole blocks of commented-out code with no explanation or documentation.
• Lots of "in flux" or "to be replaced" code areas.
• Unused (dead) code.
• Unused, inexplicable, or obsolete interfaces in header files.

Typical Causes

• R&D code placed into production without thought toward configuration management.
• Uncontrolled distribution of unfinished code. Implementation of several trial approaches toward implementing some functionality.
• Code written by a single developer.
• Lack of configuration management or compliance with process-management policies.
• Lack of architecture, or nonarchitecture-driven development. This is especially prevalent with highly transient development teams.
• Iterative development process. Often the goals of the software project are unclear or change repeatedly. To cope with the changes, the project requires rework, backtracking, and prototype development efforts. In response to a demonstration deadline, there is a tendency to make hasty changes or to code on-the-fly in order to deal with immediate problems. The code is never cleaned up, leaving architectural consideration and documentation postponed indefinitely.
• Architectural scars. Sometimes architectural commitments are made during requirements analysis, only to be deemed obsolete after some amount of development. The system architecture may be reconfigured, but these in-line mistakes are seldom removed. It may not even be feasible to comment-out unnecessary code, especially in modern development environments where hundreds of individual files comprise the code of a system.

Known Exceptions

Small-scale, throwaway prototypes in an R&D environment are ideally suited for implementing the Lava Flow AntiPattern. It is essential to deliver rapidly and the result is not required to be sustainable.

Consequences

• If existing Lava Flow code is not removed, it can continue to proliferate as code is reused in other areas.
• If the process that leads to Lava Flow is not checked, there can be a geometric growth as successive developers, too rushed or intimidated to analyze the original flows, continue to produce new, secondary flows as they try to work around the original ones.
• As the flows compound and harden, it rapidly becomes impossible to document the code or understand its architecture enough to make improvements.

Refactored Solution