A common response to a recurring problem that is usually ineffective and risks being highly counterproductive.

Antipatterns usually form over the years, as new ideas, practices or methods are added without re-analyzing the need for the existing ones. As such, solutions are found to "circumvent" common problems - but these solutions prove ineffective in the broader term and may result in undesired consequences down the line. 

Coaches and consultants like to invoke antipatterns as a way of pointing out behavior they often see in teams they coach and as an avenue of suggesting better 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:

  1. 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.
  2. Another solution exists that is documented, repeatable, and proven to be effective.


  • 1995 Andrew Koenig coins the term antipattern in the March – April 1995 edition of the Journal of Object Oriented Program: “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.”  The term was inspired by a book, Design Patterns, which highlights a number of design patterns in software development that its authors considered to be highly reliable and effective.
  • 1998 The book AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by Linda Rising popularized the term, which extended its use beyond the field of software design to refer informally to any commonly reinvented but bad solution to a problem.


  • Analysis paralysis: A project stalled in the analysis phase, unable to achieve support for any of the potential plans of approach
  • Bystander apathy: The phenomenon in which people are less likely to or do not offer help to a person in need when others are present
  • 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
  • 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 their decision
  • Stovepipe or Silos: An organizational structure of isolated or semi-isolated teams, in which too many communications take place up and down the hierarchy, rather than directly with other teams across the organization
  • Vendor lock-in: Making a system excessively dependent on an externally supplied component
  • Cart before the horse: Focusing too many resources on a stage of a project out of its sequence
  • Death march: A project whose staff, while expecting it to fail, are compelled to continue, often with much overwork, by management which is in denial
  • Over-engineering: 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
  • Gold plating: Continuing to work on a task or project well past the point at which extra effort is not adding value
  • Accidental complexity: Programming tasks which could be eliminated with better tools (as opposed to essential complexity inherent in the problem being solved)
  • Hard code: Embedding assumptions about the environment of a system in its implementation
  • Copy and paste programming: Copying (and modifying) existing code rather than creating generic solutions
  • Silver bullet: Assuming that a favorite technical solution can solve a larger process or problem

Further Reading:

The WIkipedia entry on Anti-Patterns contains a list of commonly referenced antipatterns.

Template for describing antipatterns similar to the patterns template from the C2 Wiki

AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William J. Brown, Hays W. McCormick, Scott W. Thomas and Thomas J. Mowbray

AntiPatterns and Patterns in Software Configuration Management by William J. Brown, Hays W. McCormick, and Scott W. Thomas

AntiPatterns in Product Management by William J. Brown, Hays W. McCormick, and Scott W. Thomas