From Wikipedia, the free encyclopedia

This article or section seems to contain embedded lists that may require cleanup. To meet Wikipedia's style guidelines, please help improve this article by: removing items which are not notable, encyclopedic, or helpful from the list(s); incorporating appropriate items into the main body of the article; and discussing this issue on the talk page.

In computer science, anti-patterns are specific repeated practices that appear initially to be beneficial, but ultimately result in bad consequences that outweigh the hoped-for advantages.

According to the authors of the book, AntiPatterns, there must be at least two key elements present to formally distinguish an actual anti-pattern:

1. Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results, and
2. A Refactored Solution that is clearly documented, proven-in-actual-practice and repeatable.

Often pejoratively named with clever oxymoronic Neologisms, many anti-pattern ideas amount to little more than mere mistakes, rants, unsolvable problems, or just plain bad practices to be avoided if possible. Sometimes called Pitfalls or Dark Patterns the general, informal use of the term has however come to refer to classes of commonly-reinvented bad solutions to problems. Thus, there are always many more candidate anti-patterns under debate which could never be formally considered as anti-patterns.

The term anti-pattern originates in computer science, inspired by the Gang of Four's book Design Patterns, which displayed examples of high-quality programming methods. The authors named these methods design patterns, by analogy with the same term used in architecture. The book AntiPatterns (by William Brown, Raphael Malveau, Skip McCormick and Tom Mowbray, and more recently Scott Thomas) describes anti-patterns as natural counterparts or follow-ons to the study of design patterns. By formally describing repeated mistakes, one can recognize the forces that lead to their repetition and learn how others have refactored themselves out of these broken patterns. Anti-patterns are not mentioned in the first edition of Design Patterns, which predated the term anti-pattern;^{[citation needed]} however, one of the original Gang of Four authors, the late John Vlissides, offers an endorsement on the back cover.

Avoiding anti-patterns requires diagnosing them as early as possible in the software life-cycle. The concept of anti-patterns is readily applied to engineering in general.

If a software application is garnished with the unfortunate combination or mix of too many anti-patterns, then it may be known under the expression "full monty".

Contents 1 Recognized/Known Anti-Patterns 1.1 Organizational anti-patterns 1.2 Project management anti-patterns 1.3 Team Management anti-patterns 1.4 Analysis anti-patterns 1.5 General design anti-patterns 1.5.1 Object-oriented design anti-patterns 1.6 Programming anti-patterns 1.7 Methodological anti-patterns 1.8 Configuration management anti-patterns 2 See also 3 References 4 Notes 5 External links

• Accidental Ownership: Employee is given a system that was tangentially related to their system and left to poorly maintain it without proper training, growth or focus (common among phone->network administrators in the late 90's)
• Analysis paralysis: Devoting disproportionate effort to the analysis phase of a project
• Captain in the engine room: The leader spends his time and attention on technical details, and nobody's running the ship
• Cash cow: A profitable legacy product that often leads to complacency about new products
• Continuous obsolescence: Devoting disproportionate effort to porting a system to new environments
• Cost migration: Transfer of project expenses to a vulnerable department or business partner
• Crisis mode (a.k.a Firefighting mode): Dealing with things only when they become a crisis, with the result that everything becomes a crisis
• Design by committee: The result of having many contributors to a design, but no unifying vision
• Escalation of commitment: Failing to revoke a decision when it proves wrong
• Hero-Mode: A policy of continuously relying on the heroic efforts of staff in order to meet impossible deadlines, whilst ignoring the long term cost of failing to build in software quality from the outset.
• I told you so: When the ignored warning of an expert proves justified, and this becomes the focus of attention
• Management by hope: Assuming that silence means everything is going well
• Management by neglect: Too much delegation
• Management by numbers: Paying excessive attention to quantitative management criteria, when these are non-essential or cost too much to acquire
• Management by perkele: Army-style management with no tolerance for dissent
• Management by wondering: Expecting a team to define their own objectives, and then wondering what they're doing
• Moral hazard: Insulating a decision-maker from the consequences of his or her decision.
• Mushroom management: Keeping employees uninformed and misinformed (kept in the dark and fed manure)
• Not Invented Here (a.k.a. N.I.H.): Ignoring an idea or implementation originated outside the organization
• Polishing the polish: Giving a subordinate or team a finished project to work on, prohibiting them from doing anything else, and then complaining about their productivity
• Reincarnation-wheeling the Messenger: Alternately killing the messenger, and demanding to be kept informed
• Scope creep (along with the closely related terms Complexity trap and Featuritis): Allowing the scope of a project to grow without proper control
• Stovepipe: A structure that supports mostly up-down flow of data but inhibits cross organizational communication
• Vendor lock-in: Making a system excessively dependent on an externally supplied component
• Violin string organization: A highly tuned and trimmed organization with no flexibility

• Bullet-point engineering: Adding features merely to match a competitor's marketing material.
• Death march: Everyone knows that the project is going to be a disaster - except the CEO. However, the truth remains hidden and the project is artificially kept alive until the Day Zero finally comes ("Big Bang")
• Smoke and mirrors: Demonstrating how unimplemented functions will appear
• Software bloat: Allowing successive versions of a system to demand ever more resources
• Heel Dragging Blindness: Project manager's blindness to heel dragging. Project workers (resources) tending to slow down their efforts to stretch out the project schedule because they have incentive to do so, for example if they get paid by time (not results) and there's no following project for them to seamlessly transition to

• Absentee Manager: Any situation in which the manager is invisible for long periods of time.
• Alcohol Fueled Development: Development team loses focus on primary goals due to volume of alcohol consumed during regular team meetings, lunches, evening events, social meetings.
• Cage Match Negotiator: When a manager uses a "victory at any cost" approach to management.
• Doppelganger: A manager or colleague who can be nice and easy to work with one moment, and then vicious and unreasonable the next.
• Fruitless Hoops: The manager who requires endless (often meaningless) data before making a decision.
• Golden Child: When special responsibility, opportunity, recognition, or reward is given to a team member based on personal relationships or contrary to the person’s actual performance.
• Headless Chicken: The manager who is always in a panic-stricken, fire-fighting mode.
• Leader Not Manager: The manager who is a good leader, but lacks in their administrative and managerial ability.
• Managerial Cloning: The hiring and mentoring of managers to all act and work the same: identically to their bosses.
• Manager Not Leader: The manager who is proficient at their administrative and managerial duties, but lacks leadership ability.
• Metric Abuse: The malicious or incompetent use of metrics and measurement.
• Mr. Nice Guy: The manager that strives to be everyone’s friend.
• Proletariat Hero: The “everyman” worker who is held up as the ideal, but is really just a prop for management’s increasing demands and lengthening production targets.
• Rising Upstart: The potential stars who can’t wait their time and want to forgo the requisite time to learn, mature and find their place.
• Seagull Management: Flies in, makes a lot of noise, craps all over everything, then flies away.
• Spineless Executive: The manager who does not have the courage to confront situations, take the heat for a failure, or protect their subordinates.
• Three-Headed Knight: The indecisive manager.
• Ultimate Weapon: Phenomena that are relied upon so much by their peers or organization that they become the conduit for all things.
• Warm Bodies: The worker who barely meets the minimum expectations of the job and is thusly shunted from project to project, or team to team.
• Yes man: The manager who will agree with everything the CEO says even though he has stated differently away from his presence.

• Retro-Specification: To write the Technical/Functional specification after the project has already gone live.
• Phony Requirements: All requirements are communicated to the development teams in a rapid succession of netmeeting sessions or phone calls with no Functional/Technical specification or other supporting documentation.
• Napkin Specification: The Functional/Technical specification is given to the Development team on a napkin (i.e. informally, and with insufficient detail) which is fundamentally equivalent to having no specification at all.

• Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
• Ambiguous viewpoint: Presenting a model (usually OOAD) without specifying its viewpoint
• Big ball of mud: A system with no recognizable structure
• Blob: see God object
• BOMQ: "Batch Over MQ" Over-zealous use of real-time message integration to perform infrequent but high-volume periodic batch transfers.
• Database as an IPC: Using a database to communicate between processes on one or several computers when direct IPC is more appropriate.
• Gas factory: An unnecessarily complex design
• Input kludge: Failing to specify and implement handling of possibly invalid input
• Interface bloat: Making an interface so powerful that it is extremely difficult to implement
• Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction.
• Race hazard: Failing to see the consequence of different orders of events
• Re-coupling: Introducing unnecessary object dependency
• Stovepipe system: A barely maintainable assemblage of ill-related components

• Anemic Domain Model: The use of domain model without any business logic which is not OOP because each object should have both attributes and behaviors
• BaseBean: Inheriting functionality from a utility class rather than delegating to it
• Call super: Requiring subclasses to call a superclass's overridden method
• Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
• Empty subclass failure: Creating a class that fails the "Empty Subclass Test" by behaving differently from a class derived from it without modifications
• God object: Concentrating too many functions in a single part of the design (class)
• Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
• Poltergeists: Objects whose sole purpose is to pass information to another object
• Sequential coupling: A class that requires its methods to be called in a particular order
• Singletonitis: The overuse of the singleton pattern
• YAFL (Yet Another F***ing Layer): Adding unnecessary layers to a program, library or framework. This became popular after the first book on programming patterns.
• Yo-yo problem: A structure (e.g. of inheritance) that is hard to understand due to excessive fragmentation

• Accidental complexity: Introducing unnecessary complexity into a solution
• Action at a distance: Unexpected interaction between widely separated parts of a system
• Accumulate and fire: Setting parameters for subroutines in a collection of global variables
• Blind faith: Lack of checking of (a) the correctness of a bug fix or (b) the result of a subroutine
• Boat anchor: Retaining a part of a system that no longer has any use
• Bug magnet: A block of code so infrequently invoked/tested that it will most likely fail.
• Busy spin: Consuming CPU while waiting for something to happen, usually by repeated checking instead of proper messaging
• Caching failure: Forgetting to reset an error flag when an error has been corrected
• Cargo cult programming: Using patterns and methods without understanding why
• Checking type instead of interface: Checking that an object has a specific type when only a certain contract is required. May cause Empty subclass failure.
• Code momentum: Over-constraining part of a system by repeatedly assuming things about it in other parts
• Coding by exception: Adding new code to handle each special case as it is recognized
• Error hiding: Catching an error message before it can be shown to the user and either showing nothing or showing a meaningless message
• Exception handling: Using a language's error handling system to implement normal program logic
• Ghost of VS: Using patterns such as (On Error ... Resume Next) to hide errors. Often blamed on system ghosts or previous employees.
• Hard code: Embedding assumptions about the environment of a system at many points in its implementation
• Soft Code: Storing business logic in configuration files rather than source code^[1]
• Lava flow: Retaining undesirable (redundant or low-quality) code because removing it is too expensive or has unpredictable consequences
• Loop-switch sequence: Encoding a set of sequential steps using a loop over a switch statement
• Magic numbers: Including unexplained numbers in algorithms
• Magic strings: Including literal strings in code, for comparisons, as event types etc.
• Packratting: Consuming excess memory by keeping dynamically allocated objects alive for longer than they are needed
• Parallel protectionism: When code becomes so complex and fragile that it is easier to clone a parallel infrastructure than to add a trivial attribute to existing infrastructure
• Programming by Accident: (Or Debugging by Accident) - Resolving program bugs by blindly 'correcting' items, like removing white space or rearranging lines. Instead of spending time researching root causes of bugs, time is wasted trying to fix things blindly.
• Ravioli code: Systems with lots of objects that are loosely connected
• Spaghetti code: Systems whose structure is barely comprehensible, especially because of misuse of code structures
• Superboolean logic: unnecessary comparison or abstraction of boolean arithmetic
• Superthreading: the belief that code will run faster by increasing the number of threads
• Useless exception handling: Inserting conditions to prevent a runtime-exception, but throw it manually if the condition fails. (if A not null then process(A) else throw null-exception endif)
• Wrapping in cotton wool: Commonly observered when framework methods are contained in single line methods in wrapper classes which provide no useful abstraction

• Low hanging fruit: Dealing with easier issues first while ignoring larger more complex issues. It can be thought of as to the relative ease with which scientific, philosophical and technological discoveries are made at first compared with the difficulties once the subject has already been explored.
• Copy and paste programming: Copying (and modifying) existing code rather than creating generic solutions
• De-factoring: The process of removing functionality and replacing it with documentation
• Golden hammer: Assuming that a favorite solution is universally applicable
• Improbability factor: Assuming that it is improbable that a known error will occur
• Premature optimization: Coding early-on for perceived efficiency, sacrificing good design, maintainability, and sometimes even real-world efficiency
• Programming by permutation: Trying to approach a solution by successively modifying the code to see if it works
• Reinventing the wheel: Failing to adopt an existing, adequate solution
• Reinventing the square wheel: Creating a poor solution when a good one exists
• Silver bullet: Assuming that a favorite technical solution can solve a larger process or problem
• Tester Driven Development: Software projects where new requirements are specified in bug reports

• Dependency hell: Problems with versions of required products
  • DLL hell: Problems with versions, availability and multiplication of DLLs, specifically on Microsoft Windows
  • JAR hell: Problems with different versions or locations of JAR files, usually caused by a lack of understanding of the class loading model
  • Classpath hell: Problems related to specifying libraries, their dependencies and their required version to run the application
  • Extension conflict: Problems with different extensions to Mac OS attempting to patch the same parts of the operating system

• Code smell
• List of software development philosophies

• Perl Design Patterns – A free online book
• [LAPLANTE 2005] Laplante, Phillip A.; and Colin J. Neill (2005). Antipatterns: Identification, Refactoring and Management. Auerbach Publications. ISBN 0-8493-2994-9. 
• [Brown 1998] Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Dr. Thomas J. Mowbray, Theresa Hudson (ed).) (1998). AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. John Wiley & Sons, ltd. ISBN 0-471-19713-0. .

• [Brown 1999] Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Scott W. Thomas, Theresa Hudson (ed).) (1999). Anti-Patterns and Patterns in Software Configuration Management. John Wiley & Sons, ltd. ISBN 0-471-32929-0. .

• [Brown 2000] Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Scott W. Thomas, Theresa Hudson (ed).) (2000). Anti-Patterns in Project Management. John Wiley & Sons, ltd. ISBN 0-471-36366-9. .

1. ^ Soft Coding

• AntiPatterns.com A web site maintained by the authors with several patterns defined and other related articles.
• Tutorial on anti-patterns
• Hillside's review of AntiPatterns WardsWiki Reviews.

• Anti-pattern definition - Portland Pattern Repository
• Anti-patterns catalog - Portland Pattern Repository
• Patterns of Toxic Behavior