AntiPatterns

• 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.

DaveSmith has noted that many anti-patterns come from a CorrectiveAction gone awry.

AndrewKoenig first proposed AntiPatterns to me quite some time ago, and I think he's working on a C++Report anti-patterns article.

I am working on some organizational anti-patterns. I define an anti-pattern as something that looks like a good idea, but which backfires badly when applied. (It's no fun documenting the things that most people agree won't work.) These are my favoirte ProcessAntiPatterns ...

• AppointedTeam
• DiscordantRewardMechanisms
• EgalitarianCompensation
• PlugCompatibleInterchangeableEngineers
• GeographicallyDistributedDevelopment
• ManagerControlsProcess?

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. -- JimCoplien

A few classic anti-patterns are

• AnalysisParalysis
• CreepingFeaturitis
• DesignByCommittee
• KitchenSinkDesign

I've been thinking about some specific Smalltalk coding anti-patterns as a result of 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:

• RapeAndPasteProgramming. 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.

• TrainTheTrainer
• SacrificialLamb
• CargoCult

• some programming languages are more prone to AntiPatterns than others. Is this merely flexibility, or something deeper?
• the phrase "Reduced to a previously unsolved problem" springs to mind.
• Brooks, "The Mythical Man-Month" (of which I hear there is a new edition, with two more chapters) could be seen as wholly devoted to Patterns and AntiPatterns in system engineering. 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..."

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.) -- ChuckSiska

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. -- BetsyHanesPerry

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 I were talking about this once and he came up 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. -- JimCoplien

Bruce Webster has written a book called:

"Pitfalls of Object-Oriented Development"

M&T Books, 1995 [2] ISBN 1-55851-397-3 (Order from this AmazonAssociate)

I've got to buy another copy; someone borrowed it from me, then someone borrowed it from them.... a sure sign of a good book! Anyone else read this & recognized the AntiPatterns in there? -- AshleyEngelund

And what about the infamous NotInventedHere behavioural pattern?? -- RobertPhillips

I put in a vote that the AntiPattern? template include a section to say what is wrong with it. I find myself reading some of these anti-patterns and (a) forgetting half-way through that it is an anti-pattern, and start reading it as a positive pattern, (b) trying to figure out what is wrong with it, and not doing very well. I can'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". -- AlistairCockburn

CategoryAntiPattern