Қайталанатын проблемаға тиімсіз жауаптар мен олардың салдары

Common response to a recurring problem that is usually ineffective or counterproductive
An anti pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. The term, coined in 1995 by computer programmer Andrew Koenig, was inspired by the book Design Patterns (which highlights a number of design patterns in software development that its authors considered to be highly reliable and effective) and first published in his article in the Journal of Object Oriented Programming. A further paper in 1996 presented by Michael Ackroyd at the Object World West Conference also documented anti patterns. It was, however, the 1998 book AntiPatterns that both popularized the idea and extended its scope beyond the field of software design to include software architecture and project management. Other authors have extended it further since to encompass environmental, organizational, and cultural anti patterns.

Documenting anti patterns can be an effective way to analyze a problem space and to capture expert knowledge. 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.

In software engineering, anti patterns include the big ball of mud (lack of) design, the God Class (where a single class handles all control in a program rather than control being distributed across multiple classes), magic numbers (unique values with an unexplained meaning or multiple occurrences which could be replaced with a named constant), and Poltergeists (ephemeral controller classes that only exist to invoke other methods on classes).

Project management anti patterns included in the Antipatterns book include 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 (similarly, too much planning), Fear of Success (irrational fears near to project completion), The Corncob (difficulties with people), 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), and e mail Is Dangerous (situations resulting from ill advised e mail messages).