Anti-pattern
Solution to a problem that may be commonly used but is generally a bad choice
From Wikipedia, the free encyclopedia
An anti-pattern is any common but counterproductive solution to some class of problem.[1][2] The term, coined in 1995 by Andrew Koenig, was inspired by the book Design Patterns which highlights reliable and effective software development design patterns.[3] Michael Ackroyd described anti-patterns in a paper presented at the 1996 Object World West Conference.[3] The 1998 book AntiPatterns popularized the idea and extended its scope beyond software design to include software architecture and project management.[3] Other authors have extended it further to encompass environmental, organizational, and cultural anti-patterns.[4]
An anti-pattern can be distinguished from a bad habit, bad practice, or bad idea by two traits. First, anti-patterns are commonly used processes, structures or patterns of action that initially appear to be appropriate and effective, but have greater drawbacks than benefits.[5] Second, there is another way to solve the problem that is documented, repeatable, and effective where the anti-pattern is not.
Similar to patterns, a "rule-of-three" applies: to be an anti-pattern it should have occurred at least three times.[6]
Documenting anti-patterns can help to analyze a problem space and to capture expert knowledge.[7] While some anti-pattern descriptions merely document the consequences of the pattern, good anti-pattern documentation also provides alternatives ways to minimize harm.[8]
Examples
In software engineering
In software engineering, anti-patterns include:[8]
- God object
- A single class handles all control in a program rather than control being distributed across multiple classes.
- Magic number
- A literal value with an important yet unexplained meaning which could be replaced with a named constant.
- Poltergeist
- Ephemeral controller classes that only exist to invoke other methods on classes.
- Big Ball of Mud
- A software system that lacks a perceivable architecture. Although undesirable from a software engineering point of view, such systems are common in practice due to business pressures, developer turnover and software entropy.
In project management
Project management anti-patterns included in the Antipatterns book include:[4]
- Blowhard Jamboree
- An excess of industry pundits
- Viewgraph Engineering
- Too much time spent making presentations and not enough on the actual software.
- Death by Planning
- Spending too much effort planning.
- Fear of Success
- Irrational fears near to project completion.
- The Corncob
- Difficulties with people.[vague]
- Intellectual Violence
- Intimidation through use of jargon or arcane technology
- Irrational Management
- Bad management habits.
- Smoke and Mirrors
- Excessive use of demos and prototypes by salespeople.
- Throw It Over the Wall
- Forcing fad software engineering practices onto developers without buy-in.
- Fire Drill
- Long periods of monotony punctuated by short crises.
- The Feud
- Conflicts between managers.
- e-mail Is Dangerous
- Situations resulting from ill-advised e-mail messages.
See also
- Capability Immaturity Model
- Code smell – Characteristic of source code that hints at a quality problem
- Dark pattern – Deceptive user interface designs
- Design smell – Term in computer programming
- ISO/IEC 29110: Software Life Cycle Profiles and Guidelines for Very Small Entities (VSEs)
- List of software anti-patterns
- List of software development philosophies
- List of tools for static code analysis
- Software Peter principle – Engineering term for a complex, failing project
- Software rot – Degradation or loss of the use of software over time
- The Innovator's Dilemma – 1997 book by Clayton M. Christensen
