What are Anti-Patterns?

A pattern is a common solution to a problem that occurs in many different contexts. It provides a general solution that may be specialized for a given context. Patterns capture expert knowledge about “best practices” in software design in a form that allows that knowledge to be reused and applied in the design of many different types of software. Patterns address the problem of “reinventing the wheel.”

In computer science, anti-patterns are specific repeated practices that appear initially to be beneficial, but ultimately result in bad consequences that outweigh the hoped-for advantages. They are known as anti-patterns because their use (or misuse) produces negative consequences. Anti-patterns document common mistakes made during software development as well as their solutions.

There must be at least two key elements present to formally distinguish an actual anti-pattern:

· Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results, and

· A refactored solution that is clearly documented, proven in actual practice and repeatable.

Avoiding anti-patterns requires diagnosing them as early as possible in the software life-cycle. The concept of anti-patterns is readily applied to engineering in general.

Some of the Classic Anti-Patterns are:

Organizational anti-patterns

§ I told you so: When the ignored warning of an expert proves justified, and this becomes the focus of attention.

§ Mushroom management: Keeping employees uninformed and misinformed (kept in the dark and fed manure).

§ Design by committee: The result of having many contributors to a design, but no unifying vision.

Project management anti-patterns

§ Smoke and mirrors: Demonstrating how unimplemented functions will appear.

§ Software bloat: Allowing successive versions of a system to demand ever more resources.

Analysis anti-patterns

§ Retro-specification: To write the Technical/Functional specification after the project has already gone live.

§ Napkin specification: The Functional/Technical specification is given to the Development team on a napkin (i.e., informally, and with insufficient detail) which is fundamentally equivalent to having no specification at all.

General design anti-patterns

§ Re-coupling: Introducing unnecessary object dependency.

§ Gas factory: An unnecessarily complex design.

§ Interface bloat: Making an interface so powerful that it is extremely difficult to implement Stovepipe system: A barely maintainable assemblage of ill-related components.

Object-oriented design anti-patterns

§ Singletonitis: The overuse of the singleton pattern.

§ BaseBean: Inheriting functionality from a utility class rather than delegating to it.

§ Call super: Requiring subclasses to call a superclass's overridden method.

§ Poltergeists: Objects whose sole purpose is to pass information to another object.

§ Yet Another Damn Layer: Adding unnecessary layers to a program, library or framework. This became popular after the first book on programming patterns.

Programming anti-patterns

§ Accidental complexity: Introducing unnecessary complexity into a solution.

§ Coding by exception: Adding new code to handle each special case as it is recognized.

§ Magic strings: Including literal strings in code, for comparisons, as event types etc.

§ Monkey work: Term for any general repeated support code required within projects which suffer from poor code reuse and design. Is often avoided and rushed, hence open to errors and can quickly become a Bug magnet.

§ Wrapping wool in cotton: Commonly observed when framework methods are contained in single line methods in wrapper classes which provide no useful abstraction.

Testing anti-patterns

§ Hostile testing: Antagonizing practical development solutions and workflow with over-testing procedures or over-scheduling test runs.

§ Meta-testing: Overdesigning testing procedures until it is necessary to test them, also known as "watchmen's watchmen".

§ Moving target: Continuously change design and/or implementation in order to escape established testing procedures.

§ Slave testing: Conditioning testers by means of black-mail or corruption to satisfy the stakeholders urge to flag positive compliance.