The following AntiPattern template is used throughout the remainder of this book to fully document AntiPatterns. A number of simpler AntiPatterns are contained in sidebars in a minimal format called a mini−AntiPattern (previous template). The full AntiPattern template comprises a number of required and optional sections. The core sections are the general
form of the AntiPattern and the refactored solution. They provide the solution/solution pair
that comprises an AntiPattern.
• AntiPattern Name. The AntiPattern name is a unique noun phrase. It’s intended to be
pejorative. The solution name of the pattern introduces new terminology. The name is used for future reference to the principles contained in the AntiPattern. It’s important that every AntiPattern have a name, in order to uniquely identify it. Names are critical as they form the basis for an organization’s terminology when members discuss and document software and architectures.
• Also Known As. This identifies additional popular or descriptive names and phrases for
this AntiPattern.
• Most Frequent Scale. Scale is indicated via a keyword from the reference model. This
section identifies where this AntiPattern fits into the software design−level model (refer back toFigure 2.7). Each pattern is logically placed where the AntiPattern is most applicable. A secondary consideration for placement concerns the scale of the resulting solution. You can choose from idiom, micro−architecture, framework, application, system, enterprise, or global/industry. Scale also scopes the dimensions of the solution. Some patterns define useful solutions at several scales. The form of the rescaled solutions is
also described in the AntiPattern template.
• Refactored Solution Name. This identifies the refactored solution pattern.
• Refactored Solution Type. This section contains keywords from the reference. From
SDLM, it identifies the type of action that results from the AntiPattern solution. You can choose from software, technology, process, or role. Software indicates that new software is created by the solution. Technology indicates that the solution entails acquisition of a technology or product. Process indicates that the solution entails pursuing a process. Role indicates that the solution entails assigning responsibility to an individual or group. These four different kinds of solution types are detailed as follows:
1. Software patterns comprise the overwhelming majority of the patterns included in the AntiPatterns catalog. Software patterns involve the creation of new software. The vast majority of the design patterns currently available in the industry are software patterns. 2. Technology patterns solve software problems through adoption of a technology such as
Java, as opposed to programming the capability from scratch. Technology patterns are also design patterns in that they result in software design and implementation, although the method of acquisition is different. Technology patterns may involve some
programming, for example, creating an object wrapper for a commercial software module.
3. Process patterns provide the definition of activities that are consistently repeatable for a given solution.
4. Role patterns solve software problems by allocating clear responsibilities to organizational stakeholders. Process and role patterns are included because of the significant effect that communication and the human organization have upon software problem solving. Occasionally, we have found that a simple process or clarification of responsibilities provides the most effective action lever for solving a technical problem. • Root Causes. This section contains keywords from the reference model. These are the
general causes for this AntiPattern. Derived from the section on root causes inChapter 2, choose from: haste, apathy, narrow−mindedness, sloth, avarice, ignorance, pride, or responsibility (the universal cause).
• Unbalanced Forces. This section contains keywords from the reference model, and
identifies the primal forces that are ignored, misused, or overused in this AntiPattern. The choices include management of functionality, management of performance, management of complexity, management of change, management of IT resources, and management of technology transfer. Risk is an underlying force for all of these options. Note that
management of IT resources pertains to general resource tracking and allocation issues, including finances.
• Anecdotal Evidence. This is an optional section. Often−heard phrases and comedic
material associated with this AntiPattern appear in this section.
• Background. This is an optional section. The background can contain further examples of
where problems occur or general background information that is useful or interesting. • General Form of this AntiPattern. This section often includes a diagram, which 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 gives the general description of this AntiPattern. The refactored solution resolves the general AntiPattern posed by this section.
• Symptoms and Consequences. This is a bulleted list of symptoms and consequences that
result from this AntiPattern.
• Typical Causes. This is a bulleted section in which the unique causes of this AntiPattern
are identified (in addition to the root cases identified previously).
• Known Exceptions. AntiPattern behaviors and processes are not always wrong, and often
there are specific occasions when this is the case. This section briefly identifies the primary exceptions to each full AntiPattern.
• Refactored Solutions. This section explains a refactored solution that resolves the forces
variations; those are addressed in the variations section. The solution is structured in terms of solution steps.
• Variations. This is an optional section that lists any known major variations of this
AntiPattern. In addition, if there are alternative solutions, they are described here as well. The variations section exists partly in order to enhance clarity in the general form and refactored solution sections. The solutions are explained clearly, without caveats about major options and alternative design points. The variations section includes these extensions, which expand upon the capabilities of the solution.
• Example. The example demonstrates how the solution is applied to the problem by
paralleling the details of the solution. This section typically includes the following elements: problem diagram, problem description, solution diagram, and solution description. This section includes one or more examples of the AntiPattern abstracted from experience.
• Related Solutions. This section identifies any citations or cross−references that are
appropriate. Any AntiPatterns that are closely related to this one are listed and the differences are explained. Relationships with design patterns from other pattern languages are identified and explained. Detailed citations are contained in the
bibliography in the back of the book. The references to related patterns are an important aspect of the AntiPatterns. Each AntiPattern resolves some forces and creates new ones. The new forces can be resolved by related patterns, either at the same or another level. This section also highlights differences between similar patterns.
This section also includes related terminology, references, and resources. Related
terminology is explained for two reasons: to distinguish our definitions from other terms using similar names, and to connect related concepts referred to by different names. These two ambiguities are the source of much confusion in software engineering circles. References include well−known terminology, example technologies, and relevant research. The
references are particularly useful to experts who can use this information to rapidly relate this pattern to other known work. If an expert reviewer fully understands one or more of the references, then the core ideas of the pattern are already known by a different terminology. (We have encountered this effect in the use of other pattern languages.It sometimes takes significant time to resolve these terminology differences without this useful section.) This section serves as both a reference list and as an “also−known−as” list of synonyms with respect to other work. Resources include pointers to other kinds of information and organizations that address the problem.
• Applicability to Other Viewpoints and Scales. This section defines how the AntiPattern
impacts the remaining viewpoints: managerial, architectural, or developer. It also describes the relevancy of the pattern to other levels. If a pattern assumes a different “name” at different levels, then it should be mentioned here. Some key questions addressed in this section include: What happens when the AntiPattern is applied at different levels? How effectively does it resolve the forces at the other scales? What new forces are introduced, and are they resolved as well? How do the key forces influencing the design patterns change with scale? How do the roles of the key design elements change with scale?
The AntiPatterns in Chapters 5–7 utilize this template to document the common dysfunctional practices in the software industry and suggests practical solutions that have been proven effective on at least three known occasions. These chapters discuss software development AntiPatterns, architectural AntiPatterns and managerial AntiPatterns. These levels were chosen to provide a comprehensive coverage of the critical issues involved in software projects.
Chapter 4:Advice for Using AntiPatterns
Overview
There is a danger in using AntiPatterns to change existing organizational practices. Some early adopters used AntiPatterns in a destructive manner. Although they identified similarities with several of the AntiPatterns discussed in this work, rather than serving as a catalyst for change, these anti−social practices resulted in early retirement or reassignment to distant
corporate offices. While assigning blame and pointing fingers may provide a temporary rush of satisfaction, this is not the intended use of software AntiPatterns.
It’s important to remember that every company may be suffering from several AntiPatterns at any given moment. However, the absence of AntiPatterns does not guarantee that an organization will be successful. In fact, many organizations are successful despite repeated violations of common sense—that is, AntiPatterns. Certainly, resolving an AntiPattern can result in software improvement, but you don’t have to address every AntiPattern to be successful. AntiPatterns are most appropriate for resolving chronic problems, especially when they must be proactively addressed in order to meet the organizational goals. Heed the advice: “If it’s not broken, don’t fix it; leave well enough alone.”
The purpose of AntiPatterns is not to focus on dysfunctional software practices. Rather, the purpose is the development and implementation of strategies to fix the problems that arise. Improvements to software projects are best done incrementally. A plan that involves the simultaneous correction of several AntiPatterns is risky and ill−advised. By focusing on improving processes on a case−by−case basis, according to a well−conceived plan, the chances of successfully implementing a viable solution are markedly increased. Furthermore, implementing a solution is feasible only when the technical staff has the necessary skills to address the problem. When the technical knowledge is not sufficient to fully implement an AntiPattern solution, the cure can cause problems that are as bad or worse than the original malady.