Anti-pattern

{{Short description |Solution to a problem that may be commonly used but is generally a bad choice}} {{Only primary sources|date=September 2025}}

An '''anti-pattern''' is any common but counterproductive solution to some class of problem.{{sfn|Budgen|2003|p=225}}{{sfn|Ambler|1998|p=4}} The term, coined in 1995 by Andrew Koenig, was inspired by the book ''Design Patterns'' which highlights reliable and effective software development design patterns.{{sfn|Neill|Laplante|DeFranco|2011|p=4}} Michael Ackroyd described anti-patterns in a paper presented at the 1996 Object World West Conference.{{sfn|Neill|Laplante|DeFranco|2011|p=4}} The 1998 book ''AntiPatterns'' popularized the idea and extended its scope beyond software design to include software architecture and project management.{{sfn|Neill|Laplante|DeFranco|2011|p=4}} Other authors have extended it further to encompass environmental, organizational, and cultural anti-patterns.{{sfn|Neill|Laplante|DeFranco|2011|p=5}}

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. 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.{{sfn|Neill|Laplante|DeFranco|2011|p=6}}

Documenting anti-patterns can help to analyze a problem space and to capture expert knowledge.{{sfn|Jimenez|2006}} While some anti-pattern descriptions merely document the consequences of the pattern, good anti-pattern documentation also provides alternatives ways to minimize harm.{{sfn|Demeyer|2008|p=102}}

==Examples==

===In software engineering=== In software engineering, anti-patterns include:{{sfn|Demeyer|2008|p=102}}

; 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:{{sfn|Neill|Laplante|DeFranco|2011|p=5}}

; Blowhard Jamboree: An excess of industry pundits

; Analysis paralysis

; 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|date=March 2026}}

; 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 ==  *{{annotated link|Capability Immaturity Model}} *{{annotated link|Code smell}} *{{annotated link|Dark pattern}} *{{annotated link|Design smell}} *{{annotated link|List_of_ISO_standards_28000–29999|ISO/IEC 29110}}: Software Life Cycle Profiles and Guidelines for Very Small Entities (VSEs) *List of software anti-patterns *{{annotated link|List of software development philosophies}} *{{annotated link|List of tools for static code analysis}} *{{annotated link|Software Peter principle}} * {{annotated link|Software rot}} *''{{annotated link|The Innovator's Dilemma}}''

== References == === What supports what === {{Reflist|50em}} === Sources === {{refbegin}} * {{cite book|title=Antipatterns: Managing Software Organizations and People|edition=second|series=Applied Software Engineering Series|author1-first=Colin J.|author1-last=Neill|author2-first=Philip A.|author2-last=Laplante|author3-first=Joanna F.|author3-last=DeFranco|publisher=CRC Press|year=2011|isbn=9781439862162}} * {{cite book |author-last=Budgen|author-first=D. |title=Software design |year=2003 |publisher=Addison-Wesley |location=Harlow, Eng. |isbn=0-201-72219-4 |page=225 |url=https://books.google.com/books?id=bnY3vb606bAC&q=%22anti-pattern%22+date:1990-2003&pg=PA225 |quote="As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'."}} * {{cite book |author-first=Scott W.|author-last=Ambler |author-link= Scott W. Ambler |title=Process patterns: building large-scale systems using object technology |year=1998 |publisher=Cambridge University Press |location=Cambridge, UK |isbn=0-521-64568-9 |page=4 |url=https://books.google.com/books?id=qJJk2yEeoZoC&q=%22anti-pattern%22+date:1990-2001&pg=PA4 |quote="...common approaches to solving recurring problems that prove to be ineffective. These approaches are called antipatterns."}} * {{cite web |last1=Jimenez |first1=Edward |date=2006-04-24 |title=AntiPatterns |url=http://antipatterns.com/EdJs_Paper/Antipatterns.html |website=AntiPatterns |access-date=24 April 2006}} * {{cite book|title=Software Evolution|editor1-first=Tom|editor1-last=Mens|editor2-first=Serge|editor2-last=Demeyer|publisher=Springer Science + Business Media|year=2008|isbn=9783540764403|chapter=ObjectOriented Reengineering|author1-first=Serge|author1-last=Demeyer}} {{refend}}

== Further reading == * {{cite journal|title=Patterns and Antipatterns|journal=Journal of Object-Oriented Programming|date=March–April 1995|first=Andrew|last=Koenig|volume=8 |issue=1|pages=46–48}} ** Later re-printed in: {{cite book |author=Rising, Linda |title=The patterns handbook: techniques, strategies, and applications |year=1998 |publisher=Cambridge University Press |location=Cambridge, U.K. |isbn=0-521-64818-1 |page=387 |url=https://books.google.com/books?id=HBAuixGMYWEC&q=0-521-64818-1&pg=PT1 |quote="An antipattern is just like a pattern, except that instead of a solution it gives something that looks superficially like a solution, but isn't one."}} *{{cite book |last1=Laplante |first1=Phillip A. |last2=Neill |first2=Colin J. |year=2005 |title=Antipatterns: Identification, Refactoring and Management |publisher=Auerbach Publications |isbn=0-8493-2994-9}} *{{cite book |last1=Brown |first1=William J. |last2=Malveau |first2=Raphael C. |last3=McCormick |first3=Hays W. |last4=Thomas |first4=Scott W. |editor-last=Hudson |editor-first=Theresa Hudson |title=Anti-Patterns in Project Management |publisher=John Wiley & Sons |year=2000 |isbn=0-471-36366-9}} *{{cite journal|journal=Journal of Systems and Software|volume=83|issue=1|date=January 2010|pages=52–59|title=Software project management anti-patterns|author1-first=Ioannis|author1-last=Stamelos|doi=10.1016/j.jss.2009.09.016}}

==External links== {{Commonscatinline}} *[http://c2.com/cgi/wiki?AntiPattern Anti-pattern] at WikiWikiWeb

Category:Anti-patterns Category:Software architecture Category:Design Category:Industrial and organizational psychology Category:Organizational behavior Category:Anti-social behaviour Category:Workplace Category:1995 neologisms