Anti-pattern

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.

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.

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 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

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

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 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.

Never Now: Where pervasive schedule crunches cause useful or required improvements to be perpetually deferred to some mythical time in the future when those crunches won't exist.[citation needed]

Ninety-ninety rule: 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

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

Abstraction inversion: Not exposing implemented functionality required by callers of a function/method/constructor, so that the calling code awkwardly re-implements the same functionality in terms of those calls

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). Martin Fowler considers this to be an anti-pattern, but some disagree that it is always an anti-pattern.[4]

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[6][7]

^"Revenge of the Nerds". In the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write.