Anti-pattern

An anti-pattern can be distinguished from a bad habit, bad practice, or bad idea by two traits. First, anti-patterns are commonly used processes, structures or patterns of action that initially appear to be appropriate and effective, but have greater drawbacks than benefits. Second, there is another way to solve the problem that is documented, repeatable, and effective where the anti-pattern is not.

Similar to patterns, a "rule-of-three" applies: to be an anti-pattern it should have occurred at least three times.

Documenting anti-patterns can help to analyze a problem space and to capture expert knowledge. While some anti-pattern descriptions merely document the consequences of the pattern, good anti-pattern documentation also provides alternatives ways to minimize harm.

Examples

In software engineering

In software engineering, anti-patterns include:

God object

A single class handles all control in a program rather than control being distributed across multiple classes.

Magic number

A literal value with an important yet unexplained meaning which could be replaced with a named constant.

Poltergeist

Ephemeral controller classes that only exist to invoke other methods on classes.

Big Ball of Mud

A software system that lacks a perceivable architecture. Although undesirable from a software engineering point of view, such systems are common in practice due to business pressures, developer turnover and software entropy.

In project management

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

Spending too much effort 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.

e-mail Is Dangerous

Situations resulting from ill-advised e-mail messages.