is a pattern that tells how to go from a problem to a bad solution. (Contrast to an Amelioration Pattern, which is a pattern that tells how to go from a bad solution to a good solution.)
Identifying bad practices can be as valuable as identifying good practices.
A well formulated Anti Pattern also tells you why the bad solution looks attractive (e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead.
Accordingly to Jim Coplien: "an anti-pattern is something that looks like a good idea, but which backfires badly when applied." It's not fun documenting the things that most people agree won't work, but it's necessary because many people may not recognize the Anti Pattern. "[NOTE: Some discussion of this on Thread Mode, Problems With Documentation, etc. Look around, plenty of hand-wringing over this.]"
In the old days, we used to just call these 'bad ideas'. The new name is much more diplomatic.
As we reach and pass by the 50-year mark in developing programmable digital systems, the software industry has yet to resolve some fundamental problems in how humans translate business concepts into software applications. Some could reasonably argue that the emergence of design patterns has provided the most effective form of software guidance yet available, and the whole patterns movement has gone a long way in codifying a concise terminology for conveying sophisticated computer science thinking.
While it is reasonable to assume that the principal reason people write software is to provide solutions to specific problems, it is also arguable that these solutions frequently leave us worse off than before we started. In fact, academic researchers and practitioners have developed thousands of innovative approaches to building software: from exciting new technologies to progressive processes, but with all these great ideas, the likelihood of success for practicing managers and developers is grim.
So what? Well, Anti Patterns identify and categorize the common mistakes in software practice, a target-rich environment for Anti Patterns research. Anti Patterns also identify alternative solutions. Like Analysis Patterns, Anti Patterns extend the field of design patterns research into exciting new areas and issues, including: Re Factoring, Re Engineering, system extension, and system migration. Anti Patterns knowledge is a growing treasure trove of the collective experience from thousands of years of combined software project experience as well as numerous cited works, such as Dr. William Opdyke's thesis on Refactoring, Bruce Webster's "Pitfalls of OO", the Mythical Man Month, and Yourdon's Death March Projects.
Anti Patterns are not new; they are commonplace in society, and they have been around since software's inception -- spaghetti code, for example. Anti Patterns, as a research discipline, studies what seems like a good idea at the outset, but doesn't work out in the end.
The Anti Patterns
See the Anti Patterns Catalog for a sorted (or sordid) list of Anti Patterns.
To define an Anti Pattern, you can use the Anti Pattern Template.
Discussing Anti Patterns
The point isn't as much to say "don't do this" as it is to say "you probably don't even _realize_ that you're doing this, but it doesn't work..."
The study of anti-patterns is an important research activity. The presence of "good" patterns in a successful system is not enough; you also must show that those patterns are absent in unsuccessful systems. Likewise, it is useful to show the presence of certain patterns (anti-patterns) in unsuccessful systems, and their absence in successful systems.
It seems like a rich vein to follow for Patterns Miners, maybe even the mother lode, given the number of projects gone awry in the software world. To paraphrase Edward Abbey[1] rather liberally, "There's no situation so bad that an anti-pattern can't make it worse."
No, the above (about "good" patterns) is fundamentally flawed. It very strongly implies that patterns can be "good" without reference to context. This is a common yet fundamental misunderstanding of patterns. Just because something is a pattern, doesn't mean your system will be better if you use it. I have seen very bad solutions that are such *because* they inappropriately use "good" patterns.
Also, some projects/products can succeed quite well despite the presence of one or more acknowledged "anti-patterns".
The presence or absence of "good" or "anti-" patterns is not the major contributor to success of a project/product. As a result, such a study as proposed could potentially identify good patterns as bad and bad patterns as good.
I strongly suspect that the study you allude to would give results that surprise you. Since it would remove the context from the pattern, there can be no notion of the pattern being "good" or "bad".
Sometimes people get very excited when they first hear about patterns and decide to use every pattern that they can find, regardless of its utility in the context. This leads to disaster at least as reliably as many well-acknowledged anti-patterns.
Short Comments on Anti Patterns
The phrase "Reduced to a previously unsolved problem" springs to mind.
An anti-pattern is a stereotyped "Hall of Shame" entry. (i.e., "My purpose in life is to serve as a warning to others.")
Many anti-patterns come from a Corrective Action gone awry.
Like most patterns, anti-patterns can be misused. Things might turn out well, or they may just go wrong in a different way.
Whereas good patterns are soothing and satisfying and have a good sense of catharsis, the best anti-patterns are cynical or comical.
Discussing the Definition
The definition was refactored to reflect the near-unanimous use of Anti Pattern to mean "bad solution to the given problem". I promoted the suggested term Amelioration Pattern for the "bad solution to good solution" meaning.
The original description was:
An anti-pattern is either...
A pattern that tells how to go from a problem to a bad solution, or
A pattern that tells how to go from a bad solution to a good solution.
"Or vice-versa"
with some interesting comments: The first seems particularly useless except as a place holder for the message don't do this. The second is really a positive pattern where the problem is stated as a bad solution (e.g., Functional Inversion).
I think that the first definition is useful. By taking the trouble to write an anti-pattern for a problem and solution that has proven to be bad, we get a better understanding of why it was bad... This helps us next time our projects are in danger of going down the same route. Instead of just saying "I think that is a bad approach", we can say "I think that is a bad approach for these reasons, and I think the result will be this". -- Matt Stephenson
I find it interesting that the original author's initial description of an anti-pattern discards the meaning of a bad pattern to follow and seems (in my opinion) to ask for patterns of the second kind, and yet all of the responses are with patterns of the first kind.
In my continual effort to put my foot in it (especially when without towel), I've advanced an anti-pattern in the second sense. Given the unanimous response that "anti-pattern" has the first meaning, however, I'll call it (till shouted down) an Amelioration Pattern: Functional Inversion. (Clearly, there are only so many streams I'm willing to buck - the first meaning of anti-pattern wins.)
Questions to be answered
Some programming languages are more prone to Anti Patterns than others. Is this merely flexibility, or something deeper?
Don't patterns exist as a construct within a "parent object" of Industrial Sociology?
One could argue that Only Foresight Matters. Although there is value in teaching, it is also possible that we should Never Explain, as your friends don't need it and your enemies won't believe you anyway. Basically, you should just Learn From Experience, Do The Best You Can, and Keep Your Head Down. The other main problem is that people tend to remember the things that they read that already match and reinforce their personal experiences, while downplaying or ignoring those items that go against what they have seen for themselves. As such, the Best Learning Is By Doing.
Why not call them Bad Patterns, Dangerous Patterns or Failed Patterns? Just because they didn't work in one context doesn't mean the won't in another (similarly with Design Patterns). Examining reasons why they failed is helpful as mentioned elsewhere on this page.
What about normal Design Patterns that lead to bad results in certain circumstances? Are they both Design Patterns and Anti Patterns?
How to describe Anti Patterns
The Anti Pattern Template should include a section to say what is wrong with it. If not, there is the risk to be reading some of these anti-patterns and
(a) forget half-way through that it is an anti-pattern, and start reading it as a positive pattern,
(b) try to figure out what is wrong with it, and not doing very well. One couldn't tell if the Rationale is the "pseudo-rationale which a faulty thinker would think causes this to be a valid pattern", or "the rationale about why this is an anti-pattern".
Perhaps we should be using a different font in the template, to help us to remember. Some creepy gothic germanic font, or maybe a "dripping-blood" font like from Rocky Horror. :) Or maybe the "letters-ripped-out-of-a-newspaper" font.
Almost Anti Patterns
Patterns and Anti Patterns are quite high level. Sources Of Bugs is an attempt at a low level version of this topic. Xy Symmetry Bugs are an example.
Caveat - Bug Patterns are not Anti Patterns - they are positive patterns of defect location.
Books on Anti Patterns
Anti Patterns Book [ISBN 0471197130]
Pitfalls Of Object Oriented Development [ISBN 1558513973]
The Mythical Man Month [ISBN 0201835959]
Bitter Java, Bruce Tate, [ISBN 193011043X]
History of Anti Patterns
Andrew Koenig first proposed Anti Patterns to me (who?) quite some time ago, and I think he's working on a C++Report anti-patterns article.
Since 1994, there has been an exponential growth in the publication of design pattern literature. This growth has both a bright and a dark side. To the skilled object-oriented architect, there is now a large and growing base of reusable designs which can be evaluated and applied to a software development effort. Furthermore, there is a wealth of papers and seminars to assist an architect in documenting his own domain knowledge into design patterns so they can be more readily used by other professionals who enter into the industry. However, the dark side is that many of the people who are using design patterns fail to properly evaluate how applicable a particular design pattern or pattern language to their specific set of design concerns. In addition, some developers, armed with their packaged knowledge, eagerly rush in to classify everything as a design pattern or solvable by a specific set of design pattern before attempting to perform and complete their domain analysis.
I (Skip Mc Cormick) first heard about Anti Patterns from Michael Ackoyd in his the 1996 Object World West conference entitled "Anti Patterns: Vaccinations Against Object Misuse". His presentation was based upon a detailed analysis of the object-oriented literature in the industry and was an attempt to define a common convergence of ideas about object-orientation. The presentation focused on recognizing harmful software constructs, which were reoccurring across several software projects. This is the complimentary antithesis of the GoF patterns, which emphasizes the use of proven good designs, and which can be applied in constructing new software.
Prior to Ackroyd there were others who mentioned the notion of Anti Patterns in hallways,etc. but Mike was the first I'm aware of who used it as a formal model for documenting Bad Software. The discussion of the usefulness of Anti Patterns arose almost in parallel with the introduction of patterns. Similar work on providing software guidance based on identifying dysfunctional behavior and refactoring a solution has been documented by Fred Brooks, Bruce Webster, James Coplien, and Andrew Koenig.
Since the evolution of Anti Patterns has had so many contributors, it would be unfair to assign the original idea for Anti Patterns to a single source. Rather, Anti Patterns are a natural step in complementing the work of the design pattern movement and extends the design pattern model. Anti Patterns attempt to bridge the gap between the academic formalisms of the GoF design patterns and the fledging software developers who need more contextual information in order to evaluate and determine whether a particular technique is appropriate to their particular situation.
Discussing specific Anti Patterns
Some specific Smalltalk coding anti-patterns can be derived from reading Kent's Smalltalk Best Practice Patterns. Some of them would be ...
Using Arrays instead of first class objects (i.e. representing a name as #('Kyle' 'Gene' 'Brown'))
Using dictionaries instead of instance variables (i.e. - I'll just put one instance variable in my object that contains a dictionary, and then whenever I need a value, I'll just do "self values at: #foo!")
Using the #do: iterator and an accumulator temp variable instead of using #collect:
And here's one that's about design more than coding ...
Copy And Paste Programming. This is when a programmer cruises through the image blindly copying methods and code segments into their object instead of more judiciously using inheritance and composition to achieve the same ends. While this can be a useful SHORT TERM tool, it can lead to big problems in maintenance later.
Are Crci Cards as one "bad solution to a good solution" Anti Patterns?
Other Anti Patterns
For anti-patterns that relate specifically to code structure and refactoring, see Code Smell, Classic Oo Anti Patterns.
'''Anti Patterns are Aikido Patterns?
Why not call an anti-pattern(2) a Aikido Pattern? You're using a set of forces in a way not foreseen by the force's provider to reach a positive solution.
It's an expressed consideration of Aikido to preserve the well-being of the attacker. I don't know much about Judo. Aikido is a defensive technique; I can guess that Judo is too: am I right? But isn't it one of the goals of Judo to do bodily harm to the opponent? In Aikido, you avoid bodily harm. You balance the forces, not obliterate them.
Frank Buschmann and Jim Coplien were talking about this once and Frank came up with something pretty profound, whose details I no longer remember. It goes something like this: Aikido is "one mind, one body." You must know the mind of your adversaries, and must blend your movements with theirs. Judo is "one mind, two bodies": you still must know your opponents' mind, and you still use your opponents' intents and forces against them, but you don't preserve their safety as though it were your own body.
Judo is a sport. The goal in Judo is to score a point, not to hurt your partner.
You are correct that in Aikido one assumes responsbility for one's attacker -- the general thought is that the person attacking you is mentally unstable (evidence: they are attacking you). They are therefore not responsible for their actions and need your help.
Aikido is an interesting practice to analogize with patterns. Aikido is about handling an attack (or problem) by understanding it (define problem), accepting it (decide to fix), blending with it (refactor), and redirecting it (achieve new [harmless] pattern).
Any time your solution uses the unique attributes of a problem to redirect misguided intent, you can assume that the technique was somewhat Aikido-like. -- Mental Nomad
Purpose and Scope of Anti Patterns
I see anti-patterns as a description of a bad solution to a problem. This in itself is quite a powerful feature that could be utilised to teach designers about bad solutions to problems and faults. However, exactly where does the list end and how much variation is there between one anti-pattern and another? There are an infinite number of Anti Pattern's that can be generated and a subtle difference in an Anti Pattern could end up in a completely new Anti Pattern.
The key to clarifying the scope is to identify how a Pattern and Anti Pattern for a problem relate: they both fit the signature of the problem.
This is also what distinguishes any old "bad idea" from an Anti Pattern: an Anti Pattern looks like a good idea but has some fatal flaw which it a poor solution.
As an example, consider braking in a car (in the days before antilock brakes): if the conditions involve ice, solving the "I must stop" problem by firmly depressing the brake would be an Anti Pattern: it seems like a good idea, but it has a fatal flaw in that firm braking on ice causes skidding and little deceleration. Studying the Anti Pattern teaches you to pump the brake, a more appropriate solution Pattern. -- Mental Nomad
I've seen recent computer science students use the Someone Elses Example Anti Pattern. Here they indiscriminately copy bits of example code from the web to try to glue together a Frankenstein monster of a system. Mostly witnessed from students with a managerial attitude to Software Development, or they claim they "don't need to understand it just to write it".
Collaborators: In alphabetical order: Alistair Cockburn Allan Baruz Ashley Engelund Betsy Hanes Perry Chris Brown Chuck Siska Don Olson Ed Poor Geraldo Xexeo Iain Lowe Jeff Chapman Jim Coplien Jonathan Holloway Kyle Brown Mark Eichin Robert Phillips Ron Jeffries Seth Gordon Skip Mc Cormick
See: Adding Epicycles Aikido Pattern Amelioration Pattern Anti Patterns Book Anti Patterns Catalog Anti Pattern Template Dark Pattern Grey Pattern Mythical Man Month Pet Bug Pitfalls Of Object Oriented Development Sources Of Bugs
See original on c2.com 