Anti-pattern explained

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.

Definition

According to the authors of Design Patterns, there are two key elements to an anti-pattern that distinguish it from a bad habit, bad practice, or bad idea:

  1. The anti-pattern is 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 to the problem the anti-pattern is attempting to address. This solution is documented, repeatable, and proven to be effective where the anti-pattern is not.

A guide to what is commonly used is a "rule-of-three" similar to that for patterns: to be an anti-pattern it must have been witnessed occurring at least three times.

Uses

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.

Software engineering anti-patterns

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

Big ball of mud

This indicates 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 code entropy.

The term was popularized in Brian Foote and Joseph Yoder's 1997 paper of the same name, which defines the term:

Foote and Yoder have credited Brian Marick as the originator of the "big ball of mud" term for this sort of architecture.[1]

Project management anti-patterns

Project management anti-patterns included in the Antipatterns book include:

See also

Software Life Cycle Profiles and Guidelines for Very Small Entities (VSEs)

References

Sources

Further reading

External links

Notes and References

  1. Web site: Foote . Brian . Yoder . Joseph . Big Ball of Mud . laputan.org . 26 June 1999 . 14 April 2019.

This article is licensed under the GNU Free Documentation License. It uses material from the Wikipedia article "Anti-pattern".

Except where otherwise indicated, Everything.Explained.Today is © Copyright 2009-2024, A B Cryer, All Rights Reserved. Cookie policy.