Anti-pattern

<h2 id="definition">Definition</h2>
<p>According to the authors of <i>Design Patterns</i>, there are two key elements to an anti-pattern that distinguish it from a bad habit, bad practice, or bad idea:
</p>
<ol><li>The anti-pattern is a commonly used process, structure or pattern of action that, despite initially appearing to be an appropriate and effective response to a problem, has more bad consequences than good ones.</li>
<li>Another solution exists to the problem the anti-pattern is attempting to address. This solution is documented, repeatable, and proven to be effective where the anti-pattern is not.</li></ol>
<p>A guide to what is commonly used is a "rule-of-three" similar to that for patterns: to be an anti-pattern it must have been witnessed occurring at least three times.<a class="footnote-ref" id="fnref:7" href="#fn:7"><sup>7</sup></a>
</p>
<h2 id="uses">Uses</h2>
<p>Documenting anti-patterns can be an effective way to analyze a problem space and to capture expert knowledge.<a class="footnote-ref" id="fnref:8" href="#fn:8"><sup>8</sup></a>
</p><p>While some anti-pattern descriptions merely document the adverse consequences of the pattern, good anti-pattern documentation also provides an alternative, or a means to ameliorate the anti-pattern.<a class="footnote-ref" id="fnref:9" href="#fn:9"><sup>9</sup></a>
</p>
<h2 id="software-engineering-anti-patterns">Software engineering anti-patterns</h2>
<p>In software engineering, anti-patterns include the big ball of mud (lack of) design, the <a href="/facts/God_object/QhPuNxmm">god object</a> (where a single <a href="/facts/Class_(programming)/zvzkSAtE">class</a> handles all control in a <a href="/facts/Computer_program/e38jH9N9">program</a> rather than control being distributed across multiple classes), <a href="/facts/Magic_number_(programming)/Xg7mVI7V">magic numbers</a> (unique values with an unexplained meaning or multiple occurrences which could be replaced with a named constant), and <a href="/facts/Poltergeist_(computer_programming)/8TvoHJvW">poltergeists</a> (ephemeral controller classes that only exist to invoke other methods on classes).<a class="footnote-ref" id="fnref:10" href="#fn:10"><sup>10</sup></a>
</p>
<h3>Big ball of mud</h3>
<p>This indicates a <a href="/facts/Software_system/mglVMfTA">software system</a> 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 <a href="/facts/Turnover_(employment)/eKBLh3zY">turnover</a> and <a href="/facts/Software_entropy/GKGDByaS">code entropy</a>. 
</p><p>The term was popularized in Brian Foote and Joseph Yoder's 1997 paper of the same name, which defines the term:
</p>
<blockquote>
<p>A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, <a href="/facts/Spaghetti-code/R6vTEHTI">spaghetti-code</a> jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. 
</p><p>The overall structure of the system may never have been well defined. 
</p><p>If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.
</p>
— Brian Foote and Joseph Yoder, <i>Big Ball of Mud.</i> Fourth Conference on Patterns Languages of Programs (PLoP '97/EuroPLoP '97) Monticello, Illinois, September 1997</blockquote>
<p>Foote and Yoder have credited Brian Marick as the originator of the "big ball of mud" term for this sort of architecture.<a class="footnote-ref" id="fnref:11" href="#fn:11"><sup>11</sup></a>
</p>
<h2 id="project-management-anti-patterns">Project management anti-patterns</h2>
<p>Project management anti-patterns included in the <i>Antipatterns</i> book include:
</p>
<ul><li>Blowhard Jamboree (an excess of industry pundits)</li>
<li><a href="/facts/Analysis_paralysis/Dk8arDyu">Analysis paralysis</a></li>
<li>Viewgraph Engineering (too much time spent making presentations and not enough on the actual software)</li>
<li>Death by Planning (similarly, too much planning)</li>
<li>Fear of Success (irrational fears near to project completion)</li>
<li>The Corncob (difficulties with people)</li>
<li>Intellectual Violence (intimidation through use of jargon or arcane technology)</li>
<li>Irrational Management (bad management habits)</li>
<li><a href="/facts/Smoke_and_mirrors/4eUePEpz">Smoke and Mirrors</a> (excessive use of demos and prototypes by salespeople)</li>
<li>Throw It Over the Wall (forcing fad software engineering practices onto developers without buy-in)</li>
<li>Fire Drill (long periods of monotony punctuated by short crises)</li>
<li>The Feud (conflicts between managers)</li>
<li>e-mail Is Dangerous (situations resulting from ill-advised e-mail messages).<a class="footnote-ref" id="fnref:12" href="#fn:12"><sup>12</sup></a></li></ul>
<h2 id="see-also">See also</h2>
<ul><li><a href="/facts/Code_smell/YKGhPl9c">Code smell</a> – Computer programming characteristic</li>
<li><a href="/facts/Design_smell/nL19a6jH">Design smell</a> – Term in computer programming</li>
<li><a href="/facts/Dark_pattern/BjlAJKbD">Dark pattern</a> – Deceptive user interface designs</li>
<li><a href="/facts/List_of_software_development_philosophies/5K3JNWYT">List of software development philosophies</a></li>
<li><a href="/facts/List_of_tools_for_static_code_analysis/E9bcvnrD">List of tools for static code analysis</a></li>
<li><a href="/facts/Software_rot/B8JEM04X">Software rot</a> – Process of software deterioration</li>
<li><a href="/facts/Software_Peter_principle/QWXr1LBL">Software Peter principle</a> – Engineering term for a complex, failing project</li>
<li><a href="/facts/Capability_Immaturity_Model/Qlst1FFL">Capability Immaturity Model</a></li>
<li><a href="/facts/List_of_ISO_standards_28000%25E2%2580%259329999/RFjQmMeb">ISO/IEC 29110</a>: Software Life Cycle Profiles and Guidelines for Very Small Entities (VSEs)</li>
<li>List of software anti-patterns</li>
<li><i><a href="/facts/The_Innovator%2527s_Dilemma/KvVeqKUV">The Innovator's Dilemma</a> – 1997 book by Clayton M. Christensen</i></li></ul>

<h3>What supports what</h3>

<h3>Sources</h3>

<ul><li>Neill, Colin J.; Laplante, Philip A.; DeFranco, Joanna F. (2011). <i>Antipatterns: Managing Software Organizations and People</i>. Applied Software Engineering Series (second ed.). CRC Press. <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 9781439862162.</li>
<li>Budgen, D. (2003). <a href="https://books.google.com/books?id=bnY3vb606bAC&q=%22anti-pattern%22+date:1990-2003&pg=PA225"><i>Software design</i></a>. Harlow, Eng.: Addison-Wesley. p. 225. <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 0-201-72219-4. As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'.</li>
<li><a href="/facts/Scott_W._Ambler/rAh5heJo">Ambler, Scott W.</a> (1998). <a href="https://books.google.com/books?id=qJJk2yEeoZoC&q=%22anti-pattern%22+date:1990-2001&pg=PA4"><i>Process patterns: building large-scale systems using object technology</i></a>. Cambridge, UK: Cambridge University Press. p. 4. <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 0-521-64568-9. ...common approaches to solving recurring problems that prove to be ineffective. These approaches are called antipatterns.</li>
<li>Jimenez, Edward (2006-04-24). <a href="http://antipatterns.com/EdJs_Paper/Antipatterns.html">"AntiPatterns"</a>. <i>AntiPatterns</i>. Retrieved 24 April 2006.</li>
<li>Demeyer, Serge (2008). "ObjectOriented Reengineering". In Mens, Tom; Demeyer, Serge (eds.). <i>Software Evolution</i>. Springer Science + Business Media. <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 9783540764403.</li></ul>

<h2 id="further-reading">Further reading</h2>
<ul><li>Koenig, Andrew (March–April 1995). "Patterns and Antipatterns". <i>Journal of Object-Oriented Programming</i>. 8 (1): 46–48.
<ul><li>Later re-printed in: Rising, Linda (1998). <a href="https://books.google.com/books?id=HBAuixGMYWEC&q=0-521-64818-1&pg=PT1"><i>The patterns handbook: techniques, strategies, and applications</i></a>. Cambridge, U.K.: Cambridge University Press. p. 387. <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 0-521-64818-1. 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.</li></ul></li>
<li>Laplante, Phillip A.; Neill, Colin J. (2005). <i>Antipatterns: Identification, Refactoring and Management</i>. Auerbach Publications. <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 0-8493-2994-9.</li>
<li>Brown, William J.; Malveau, Raphael C.; McCormick, Hays W.; Thomas, Scott W. (2000). Hudson, Theresa Hudson (ed.). <i>Anti-Patterns in Project Management</i>. <a href="/facts/John_Wiley_%2526_Sons/53g3LqJc">John Wiley & Sons</a>. <a href="/facts/ISBN_(identifier)/15AdSPa9">ISBN</a> 0-471-36366-9.</li>
<li>Stamelos, Ioannis (January 2010). "Software project management anti-patterns". <i>Journal of Systems and Software</i>. 83 (1): 52–59. <a href="/facts/Doi_(identifier)/muM9Etpq">doi</a>:<a href="https://doi.org/10.1016%2Fj.jss.2009.09.016">10.1016/j.jss.2009.09.016</a>.</li></ul>
<h2 id="external-links">External links</h2>

Wikimedia Commons has media related to Anti-patterns.

<ul><li><a href="http://c2.com/cgi/wiki?AntiPattern">Anti-pattern</a> at <a href="/facts/WikiWikiWeb/K13WVqo1">WikiWikiWeb</a></li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1"><p>Budgen 2003, p. 225. - Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley. p. 225. ISBN 0-201-72219-4. As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'. <a href="https://books.google.com/books?id=bnY3vb606bAC&q=%22anti-pattern%22+date:1990-2003&pg=PA225" target="_blank">https://books.google.com/books?id=bnY3vb606bAC&q=%22anti-pattern%22+date:1990-2003&pg=PA225</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li>
<li id="fn:2"><p>Ambler 1998, p. 4. - Ambler, Scott W. (1998). Process patterns: building large-scale systems using object technology. Cambridge, UK: Cambridge University Press. p. 4. ISBN 0-521-64568-9. ...common approaches to solving recurring problems that prove to be ineffective. These approaches are called antipatterns. <a href="https://books.google.com/books?id=qJJk2yEeoZoC&q=%22anti-pattern%22+date:1990-2001&pg=PA4" target="_blank">https://books.google.com/books?id=qJJk2yEeoZoC&q=%22anti-pattern%22+date:1990-2001&pg=PA4</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li>
<li id="fn:3"><p>Neill, Laplante & DeFranco 2011, p. 4. - Neill, Colin J.; Laplante, Philip A.; DeFranco, Joanna F. (2011). Antipatterns: Managing Software Organizations and People. Applied Software Engineering Series (second ed.). CRC Press. ISBN 9781439862162. <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li>
<li id="fn:4"><p>Neill, Laplante & DeFranco 2011, p. 4. - Neill, Colin J.; Laplante, Philip A.; DeFranco, Joanna F. (2011). Antipatterns: Managing Software Organizations and People. Applied Software Engineering Series (second ed.). CRC Press. ISBN 9781439862162. <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li>
<li id="fn:5"><p>Neill, Laplante & DeFranco 2011, p. 4. - Neill, Colin J.; Laplante, Philip A.; DeFranco, Joanna F. (2011). Antipatterns: Managing Software Organizations and People. Applied Software Engineering Series (second ed.). CRC Press. ISBN 9781439862162. <a href="#fnref:5" class="footnote-back-ref">↩</a></p></li>
<li id="fn:6"><p>Neill, Laplante & DeFranco 2011, p. 5. - Neill, Colin J.; Laplante, Philip A.; DeFranco, Joanna F. (2011). Antipatterns: Managing Software Organizations and People. Applied Software Engineering Series (second ed.). CRC Press. ISBN 9781439862162. <a href="#fnref:6" class="footnote-back-ref">↩</a></p></li>
<li id="fn:7"><p>Neill, Laplante & DeFranco 2011, p. 6. - Neill, Colin J.; Laplante, Philip A.; DeFranco, Joanna F. (2011). Antipatterns: Managing Software Organizations and People. Applied Software Engineering Series (second ed.). CRC Press. ISBN 9781439862162. <a href="#fnref:7" class="footnote-back-ref">↩</a></p></li>
<li id="fn:8"><p>Jimenez 2006. - Jimenez, Edward (2006-04-24). "AntiPatterns". AntiPatterns. Retrieved 24 April 2006. <a href="http://antipatterns.com/EdJs_Paper/Antipatterns.html" target="_blank">http://antipatterns.com/EdJs_Paper/Antipatterns.html</a> <a href="#fnref:8" class="footnote-back-ref">↩</a></p></li>
<li id="fn:9"><p>Demeyer 2008, p. 102. - Demeyer, Serge (2008). "ObjectOriented Reengineering". In Mens, Tom; Demeyer, Serge (eds.). Software Evolution. Springer Science + Business Media. ISBN 9783540764403. <a href="#fnref:9" class="footnote-back-ref">↩</a></p></li>
<li id="fn:10"><p>Demeyer 2008, p. 102. - Demeyer, Serge (2008). "ObjectOriented Reengineering". In Mens, Tom; Demeyer, Serge (eds.). Software Evolution. Springer Science + Business Media. ISBN 9783540764403. <a href="#fnref:10" class="footnote-back-ref">↩</a></p></li>
<li id="fn:11"><p>Foote, Brian; Yoder, Joseph (26 June 1999). "Big Ball of Mud". laputan.org. Retrieved 14 April 2019. <a href="http://www.laputan.org/mud/mud.html#BigBallOfMud" target="_blank">http://www.laputan.org/mud/mud.html#BigBallOfMud</a> <a href="#fnref:11" class="footnote-back-ref">↩</a></p></li>
<li id="fn:12"><p>Neill, Laplante & DeFranco 2011, p. 5. - Neill, Colin J.; Laplante, Philip A.; DeFranco, Joanna F. (2011). Antipatterns: Managing Software Organizations and People. Applied Software Engineering Series (second ed.). CRC Press. ISBN 9781439862162. <a href="#fnref:12" class="footnote-back-ref">↩</a></p></li>
</ol>

Anti-pattern open-in-new

Anti-pattern