Antipatterns are common practices that initially appear to be beneficial, but ultimately result in bad consequences that outweigh hoped-for advantages. The term, coined in 1995 by programmer Andrew Koenig, was inspired by a book, ‘Design Patterns,’ in which the authors highlighted a number of practices 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 (over-analyzing a situation while indefinitely delaying making a decision), cargo cult programming (the ritual inclusion of code that serves no real purpose), death march (pressing ahead on a project members feel is destined to fail), groupthink (a desire for harmony in the group results in an irrational decision-making outcome), and vendor lock-in (preventing customers from seeking alternatives).
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: 1) 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 2) A good alternative solution exists that is documented, repeatable and proven to be effective.
Examples of antipatterns in organizational management include: 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 decision is known to be wrong, but the people who notice stay silent until it affects them directly); Cash cow (a profitable legacy product that often leads to complacency about new products); Design by committee (too many contributors to a design, and no unifying vision); Escalation of commitment (failing to revoke a decision when it proves wrong); Lost in the weeds (decision-making stalled by focusing on minor details); Management by perkele (authoritarian leadership that is intolerant of dissent); Management by objectives (focusing exclusively on quantitative management criteria, i.e. ‘bean counting’); Micromanagement (excessive observation, supervision, or other hands-on involvement from management); Moral hazard (insulating decision-makers from the consequences their decisions); Mushroom management (keeping employees ‘in the dark and fed manure’ or ‘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 (managers that only interact with employees when a problem arises, i.e. 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 horizontally); Top-down management (all decisions and ideas start at the top and are passed down through successive levels); and Typecasting (locking successful employees into overly-safe, narrowly-defined, predictable roles based on their past successes rather than their potential).
Pitfalls of project management include: Buzzword Driven Development (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 (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 many resources on a stage of a project out of its sequence); Ninety-ninety rule (a tendency to underestimate the amount of time to complete a project when it is ‘nearly done’); 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); Feature 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; Smoke and mirrors (demonstrating unimplemented functions as if they were already implemented); and Software bloat (allowing successive versions of a system to demand ever more resources).
Antipatterns common to software design include: Big ball of mud (a system with no recognizable structure); Gold plating (continuing to work on a task or project well past the point at which extra effort is adding value); God object (concentrating too many functions in a single part of the design); Accidental complexity (introducing unnecessary steps into a solution); Action at a distance (unexpected interaction between widely separated parts of a system); Boat anchor (retaining a part of a system that no longer has any use); Error hiding (catching an error message before it can be shown to the user and either showing nothing or showing a meaningless message); Lava flow (retaining undesirable code because removing it is too expensive or has unpredictable consequences); Magic numbers (including unexplained numbers in algorithms); Shotgun surgery (adding features which span a multiplicity of implementations in a single change); Spaghetti code (programs whose structure is barely comprehensible, especially because of misuse of code structures); and Lasagna code (programs whose structure consists of too many layers); Copy and paste programming (duplicating existing code rather than creating generic solutions); Golden hammer or Silver bullet (assuming that a favorite solution is universally applicable); Not Invented Here (reinventing the wheel instead of using an existing, adequate solution); Invented Here (dismissing any innovation originating from inside the organization due to lack of confidence in the staff); and Premature optimization (coding early-on for perceived efficiency, sacrificing good design, maintainability, and sometimes even real-world efficiency).
The Daily Omnivore 
Leave a Reply