Anti Pattern

An AntiPattern is a pattern that tells how to go from a problem to a bad solution. (Contrast to an AmeliorationPattern, 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 AntiPattern 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 JimCoplien: "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 AntiPattern. "[NOTE: Some discussion of this on ThreadMode, ProblemsWithDocumentation, 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, AntiPatterns identify and categorize the common mistakes in software practice, a target-rich environment for AntiPatterns research. AntiPatterns also identify alternative solutions. Like Analysis Patterns, AntiPatterns extend the field of design patterns research into exciting new areas and issues, including: ReFactoring, ReEngineering, system extension, and system migration. AntiPatterns 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 MythicalManMonth, and Yourdon's Death March Projects.

AntiPatterns are not new; they are commonplace in society, and they have been around since software's inception -- spaghetti code, for example. AntiPatterns, as a research discipline, studies what seems like a good idea at the outset, but doesn't work out in the end.

The AntiPatterns

See the AntiPatternsCatalog for a sorted (or sordid) list of AntiPatterns.

To define an AntiPattern, you can use the AntiPatternTemplate.

Discussing AntiPatterns

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 PatternsMiners, maybe even the mother lode, given the number of projects gone awry in the software world. To paraphrase EdwardAbbey[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 AntiPatterns

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 CorrectiveAction 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 AntiPattern to mean "bad solution to the given problem". I promoted the suggested term AmeliorationPattern 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., FunctionalInversion).

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". -- MattStephenson?

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: FunctionalInversion. (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 AntiPatterns than others. Is this merely flexibility, or something deeper?

Don't patterns exist as a construct within a "parent object" of IndustrialSociology?

One could argue that OnlyForesightMatters. Although there is value in teaching, it is also possible that we should NeverExplain, as your friends don't need it and your enemies won't believe you anyway. Basically, you should just LearnFromExperience, DoTheBestYouCan, and KeepYourHeadDown. 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 BestLearningIsByDoing.

Why not call them BadPatterns?, DangerousPatterns? or FailedPatterns?? Just because they didn't work in one context doesn't mean the won't in another (similarly with DesignPatterns). Examining reasons why they failed is helpful as mentioned elsewhere on this page.

What about normal DesignPatterns that lead to bad results in certain circumstances? Are they both DesignPatterns and AntiPatterns?

How to describe AntiPatterns

The AntiPatternTemplate 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 RockyHorror. :) Or maybe the "letters-ripped-out-of-a-newspaper" font.

Almost AntiPatterns

Patterns and AntiPatterns are quite high level. SourcesOfBugs is an attempt at a low level version of this topic. XySymmetryBugs are an example.

Caveat - BugPatterns are not AntiPatterns - they are positive patterns of defect location.

Books on AntiPatterns

AntiPatternsBook ISBN 0471197130
PitfallsOfObjectOrientedDevelopment ISBN 1558513973
The MythicalManMonth ISBN 0201835959
Bitter Java, Bruce Tate, ISBN 193011043X

History of AntiPatterns

AndrewKoenig first proposed AntiPatterns 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 (SkipMcCormick) first heard about AntiPatterns from MichaelAckoyd? in his the 1996 ObjectWorld? West conference entitled "AntiPatterns: 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 AntiPatterns in hallways,etc. but Mike was the first I'm aware of who used it as a formal model for documenting BadSoftware?. The discussion of the usefulness of AntiPatterns 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 FredBrooks, BruceWebster?, JamesCoplien, and AndrewKoenig.

Since the evolution of AntiPatterns has had so many contributors, it would be unfair to assign the original idea for AntiPatterns to a single source. Rather, AntiPatterns are a natural step in complementing the work of the design pattern movement and extends the design pattern model. AntiPatterns 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 AntiPatterns

Some specific Smalltalk coding anti-patterns can be derived from reading Kent's SmalltalkBestPracticePatterns. 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 ...

CopyAndPasteProgramming. 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 CrciCards as one "bad solution to a good solution" AntiPatterns?

IsJtwoeeAnAntiPattern

Other AntiPatterns

For anti-patterns that relate specifically to code structure and refactoring, see CodeSmell, ClassicOoAntiPatterns.

AntiPatterns are AikidoPattern's?

Why not call an anti-pattern(2) a AikidoPattern? 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.

FrankBuschmann and JimCoplien 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. -- MentalNomad?

Purpose and Scope of AntiPatterns

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 AntiPattern's that can be generated and a subtle difference in an AntiPattern could end up in a completely new AntiPattern.

The key to clarifying the scope is to identify how a Pattern and AntiPattern for a problem relate: they both fit the signature of the problem.

This is also what distinguishes any old "bad idea" from an AntiPattern: an AntiPattern 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 AntiPattern: 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 AntiPattern teaches you to pump the brake, a more appropriate solution Pattern. -- MentalNomad?

I've seen recent computer science students use the SomeoneElsesExample AntiPattern. 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 SoftwareDevelopment, or they claim they "don't need to understand it just to write it".

Collaborators: In alphabetical order: AlistairCockburn AllanBaruz AshleyEngelund BetsyHanesPerry ChrisBrown ChuckSiska DonOlson EdPoor GeraldoXexeo IainLowe JeffChapman JimCoplien JonathanHolloway KyleBrown MarkEichin RobertPhillips RonJeffries SethGordon SkipMcCormick

See: AddingEpicycles AikidoPattern AmeliorationPattern AntiPatternsBook AntiPatternsCatalog AntiPatternTemplate DarkPattern GreyPattern MythicalManMonth PetBug PitfallsOfObjectOrientedDevelopment SourcesOfBugs

CategoryAntiPattern