Anti-pattern

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Eric Corbett (talk | contribs) at 15:09, 23 April 2014 (→‎Programming). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

For the book, see AntiPatterns.

An anti-pattern (or antipattern) is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive.[1][2] The term, coined in 1995 by Andrew Koenig,[3] was inspired by a book, Design Patterns, in which the authors highlighted a number of design patterns in software development that they considered to be highly reliable and effective.

The term was popularized three years later by the book AntiPatterns, which extended its use beyond the field of software design and into general social interaction and may be used informally to refer to any commonly reinvented but bad solution to a problem. Examples include analysis paralysis, cargo cult programming, death march (software development), groupthink and vendor lock-in.

Definition

According to the authors of Design Patterns, there must be at least two key elements present to formally distinguish an actual anti-pattern from a simple bad habit, bad practice, or bad idea:

  • A commonly used process, structure or pattern of action that despite initially appearing to be an appropriate and effective response to a problem, typically has more bad consequences than beneficial results, and
  • A good alternative solution exists that is documented, repeatable and proven to be effective.

Examples

Social and business operations

Organizational

  • Analysis paralysis: A project stalled in the analysis phase, unable to achieve support for any of the potential plans of approach
  • Bleeding edge: Operating with cutting-edge technologies that are still untested and/or unstable, leading to cost overruns, under-performance, and/or delayed delivery
  • Bystander apathy: A state where a decision is known to be wrong, but the people who notice this do nothing because it affects a different group of people
  • Cash cow: A profitable legacy product that often leads to complacency about new products
  • 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
  • Groupthink: A collective state where group members begin to often unknowingly think alike and reject differing viewpoints
  • Lost in the weeds: Decision-making stalled by focusing too much on tiny details
  • Management by perkele: Authoritarian style of management with no tolerance of dissent
  • Management by objectives: Management by numbers, focus exclusively on quantitative management criteria, when these are non-essential or cost too much to acquire
  • Micromanagement: Ineffectiveness from excessive observation, supervision, or other hands-on involvement from management
  • Moral hazard: Insulating a decision-maker from the consequences of his or her decision
  • Mushroom management: Keeping employees "in the dark and fed manure" (also "left to stew and finally canned")
  • Peter Principle: Continually promoting otherwise well-performing employees up to their level of incompetence, where they remain indefinitely
  • Revolving door: An organization or team with high staff turnover that struggles to be effective, especially in maintaining continuity or business knowledge
  • Seagull management: management in which managers only interacts with employees when a problem arises, when they "fly in, make a lot of noise, dump on everyone, then fly out."
  • Stovepipe or Silos: An organizational structure of isolated teams that communicate effectively up and down but not across the organizational
  • Top-down management: A style of management where decisions and ideas too often start at the top and are passed down through successive levels
  • Typecasting: Locking successful employees into overly-safe, narrowly-defined, predictable roles based on their past successes rather than their potential
  • Vendor lock-in: Making a system excessively dependent on an externally supplied component

Project management

  • Avalanche: An inappropriate mashup of the Waterfall model and Agile Development techniques
  • Buzzword Driven Development (BDD): Adopting new technologies or business methods that are poorly-fitting or add no value, often unknowingly, simply because they are the latest crazes in the industry
  • Cadillac approach: Wrongly assuming that the most expensive tools, staff, and other resources are the best guarantee of a project's success
  • Cart-before-the-horse: Focusing too much resources on a stage of a project out of its sequence
  • Death march: A project that everyone knows will be a disaster – except the CEO – so the truth is hidden to prevent immediate cancellation of the project - (although the CEO often knows and does it anyway to maximize profit). However, the truth remains hidden and the project is artificially kept alive until the Day Zero finally comes ("Big Bang"). Alternative definition: Employees are pressured to work late nights and weekends on a project with an unreasonable deadline.
  • Resume-builder: A project whose participants are motivated heavily by developing specific marketable career skills, rather than delivering value to the organization or client
  • Overengineering: Spending resources making a project more robust and complex than is needed
  • Scope Creep: Uncontrolled changes or continuous growth in a project’s scope, or adding new features to the project after the original requirements have been drafted and accepted. (Also known as requirement creep and feature creep.)
  • Smoke and mirrors: Demonstrating unimplemented functions as if they were already implemented
  • Software bloat: Allowing successive versions of a system to demand ever more resources

Software engineering

Software design

Object-oriented programming

  • Anemic Domain Model: The use of the domain model without any business logic. The domain model's objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside (most likely in multiple places).
  • 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
  • Circular dependency: Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
  • Constant interface: Using interfaces to define constants
  • 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
  • Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
  • 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
  • Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

Programming

  • Accidental complexity: Introducing unnecessary complexity into a solution
  • Action at a distance: Unexpected interaction between widely separated parts of a system
  • 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
  • Busy waiting: Consuming CPU while waiting for something to happen, usually by repeated checking instead of 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
  • 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. Also can refer to erasing the Stack trace during exception handling, which can hamper debugging.
  • Hard code: Embedding assumptions about the environment of a system in its implementation
  • Lava flow: Retaining undesirable (redundant or low-quality) code because removing it is too expensive or has unpredictable consequences[4][5]
  • Loop-switch sequence: Encoding a set of sequential steps using a switch within a loop statement
  • Magic numbers: Including unexplained numbers in algorithms
  • Magic strings: Including literal strings in code, for comparisons, as event types etc.
  • Repeating yourself: Writing code which contains repetitive patterns and substrings over again; avoid with once and only once (abstraction principle)
  • Shotgun surgery: Developer adds features to an application codebase which span a multiplicity of implementors or implementations in a single change.
  • Soft code: Storing business logic in configuration files rather than source code[6]
  • Spaghetti code: Programs whose structure is barely comprehensible, especially because of misuse of code structures
  • Lasagna code: Programs whose structure consists of too many layers

Methodological

  • Copy and paste programming: Copying (and modifying) existing code rather than creating generic solutions
  • Golden hammer: Assuming that a favorite solution is universally applicable (See: Silver Bullet)
  • Improbability factor: Assuming that it is improbable that a known error will occur
  • Not Invented Here (NIH) syndrome: The tendency towards reinventing the wheel (Failing to adopt an existing, adequate solution)
  • Invented Here: The tendency towards dismissing any innovation or less than trivial solution originating from inside the organization, usually because of lack of confidence in the staff
  • Premature optimization: Coding early-on for perceived efficiency, sacrificing good design, maintainability, and sometimes even real-world efficiency
  • Programming by permutation (or "programming by accident", or "programming by coincidence"): Trying to approach a solution by successively modifying the code to see if it works
  • Reinventing the square wheel: Failing to adopt an existing solution and instead adopting a custom solution which performs much worse than the existing one
  • Silver bullet: Assuming that a favorite technical solution can solve a larger process or problem
  • Tester Driven Development: Software projects in which new requirements are specified in bug reports

Configuration management

See also

References

  1. ^ 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'."
  2. ^ Scott W. Ambler (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."
  3. ^ Koenig, Andrew (March–April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming. 8 (1): 46–48.; was later re-printed in the: Rising, Linda (1998). The patterns handbook: techniques, strategies, and applications. Cambridge, U.K.: Cambridge University Press. p. 387. ISBN 0-521-64818-1. "Anti-pattern is just like pattern, except that instead of solution it gives something thats looks superficially like a solution, but isn't one."
  4. ^ Lava Flow at antipatterns.com
  5. ^ "Undocumented 'lava flow' antipatterns complicate process". Icmgworld.com. 14 January 2002. Retrieved 3 May 2010.
  6. ^ Papadimoulis, Alex (10 April 2007). "Soft Coding". thedailywtf.com. Retrieved 27 June 2011.

Further reading

  1. Laplante, Phillip A.; Neill, Colin J. (2005). Antipatterns: Identification, Refactoring and Management. Auerbach Publications. ISBN 0-8493-2994-9.
  2. Brown, William J.; Malveau, Raphael C.; McCormick, Hays W.; Thomas, Scott W. (2000). Hudson, Theresa Hudson (ed.). Anti-Patterns in Project Management. John Wiley & Sons. ISBN 0-471-36366-9.

External links

Retrieved from "https://en.wikipedia.org/w/index.php?title=Anti-pattern&oldid=605464695"