Anti-pattern

From Wikipedia, the free encyclopedia

For the book, see AntiPatterns.

In software engineering, an anti-pattern (or antipattern) is a design pattern that appears obvious but is ineffective or far from optimal in practice.[1][2]

The term was coined in 1995 by Andrew Koenig,[3] inspired by Gang of Four's book Design Patterns, which developed the concept of design patterns in the software field. The term was widely popularized three years later by the book AntiPatterns, which extended the use of the term beyond the field of software design and into general social interaction. According to the authors of the latter, 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:

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

Often pejoratively named with clever oxymoronic neologisms, many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible. Sometimes called pitfalls or dark patterns, this informal use of the term has come to refer to classes of commonly reinvented bad solutions to problems. Thus, many candidate anti-patterns under debate would not be formally considered anti-patterns.

By formally describing repeated mistakes, one can recognize the forces that lead to their repetition and learn how others have refactored themselves out of these broken patterns.

Contents

[edit] Known anti-patterns

[edit] Organizational anti-patterns

  • Analysis paralysis: Devoting disproportionate effort to the analysis phase of a project
  • Cash cow: A profitable legacy product that often leads to complacency about new products
  • Cost migration: Transfer of project expenses to a vulnerable department or business partner
  • Crisis mode (a.k.a firefighting mode): Dealing with things only when they become a crisis, with the result that everything becomes a crisis
  • Design by committee: The result of having many contributors to a design, but no unifying vision
  • Escalation of commitment: Failing to revoke a decision when it proves wrong
  • Management by neglect: Too much delegation
  • Management by numbers: Paying excessive attention to quantitative management criteria, when these are non-essential or cost too much to acquire
  • Management by perkele: Authoritarian style of management with no tolerance for dissent
  • Management by wondering: Expecting a team to define their own objectives, and then wondering what they're doing
  • Milk Monitor Promotion: A pseudo promotion (a better sounding title), with no additional responsibilities or pay increase, which is given as a quick and costless way to make the employee work harder.[clarify]
  • Moral hazard: Insulating a decision-maker from the consequences of his or her decision.
  • Mushroom management: Keeping employees uninformed and misinformed (kept in the dark and fed manure)
  • Stovepipe: A structure that supports mostly up-down flow of data but inhibits cross organizational communication
  • Vendor lock-in: Making a system excessively dependent on an externally supplied component
  • Violin string organization: A highly tuned and trimmed organization with no flexibility

[edit] Project management anti-patterns

  • Death march: Everyone knows that the project is going to be a disaster - except the CEO. However, the truth remains hidden and the project is artificially kept alive until the Day Zero finally comes ("Big Bang")
  • Smoke and mirrors: Demonstrating how unimplemented functions will appear
  • Software bloat: Allowing successive versions of a system to demand ever more resources

[edit] Team management anti-patterns

  • Cage match negotiator: When a manager uses a "victory at any cost" approach to management.
  • Doppelganger: A manager or colleague who can be nice and easy to work with one moment, and then vicious and unreasonable the next.
  • Fruitless hoops: The manager who requires endless (often meaningless) data before making a decision.
  • Headless chicken: The manager who is always in a panic-stricken, fire-fighting mode.
  • Leader not manager: The manager who is a good leader, but lacks in their administrative and managerial ability.
  • Managerial cloning: The hiring and mentoring of managers to all act and work the same: identically to their bosses.
  • Manager not leader: The manager who is proficient at their administrative and managerial duties, but lacks leadership ability.
  • Mr. nice guy: The manager that strives to be everyone’s friend.
  • Proletariat hero: The "everyman" worker who is held up as the ideal, but is really just a prop for management's increasing demands and lengthening production targets.
  • Rising upstart: The potential stars who can’t wait their time and want to forgo the requisite time to learn, mature and find their place.
  • Seagull management (hit-and-run management): The manager flies in, makes a lot of noise, craps all over everything, then flies away.
  • Three-headed knight: The indecisive manager.
  • Ultimate weapon: Phenomena that are relied upon so much by their peers or organization that they become the conduit for all things.
  • Yes man: The manager who will agree with everything the CEO says, but changes mind away from his presence.

[edit] Analysis anti-patterns

  • 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.
  • Phony requirements: All requirements are communicated to the development teams in a rapid succession of netmeeting sessions or phone calls with no Functional/Technical specification or other supporting documentation.
  • Retro-specification: To write the Technical/Functional specification after the project has already gone live.

[edit] Software design anti-patterns

  • Abstraction inversion: Not exposing implemented functionality required by users, so that they re-implement it using higher level functions
  • Ambiguous viewpoint: Presenting a model (usually OOAD) without specifying its viewpoint
  • Big ball of mud: A system with no recognizable structure
  • Blob: Generalization of God object from object-oriented design
  • Gas factory: An unnecessarily complex design
  • Input kludge: Failing to specify and implement handling of possibly invalid input
  • Interface bloat: Making an interface so powerful that it is extremely difficult to implement
  • Magic pushbutton: Coding implementation logic directly within interface code, without using abstraction.
  • Race hazard: Failing to see the consequence of different orders of events
  • Railroaded solution: A proposed solution that while poor, is the only one available due to poor foresight and inflexibility in other areas of the design
  • Re-coupling: Introducing unnecessary object dependency
  • Stovepipe system: A barely maintainable assemblage of ill-related components
  • Staralised schema: A database schema containing dual purpose tables for normalised and datamart use

[edit] Object-oriented design anti-patterns

  • Anemic Domain Model: The use of domain model without any business logic which is not OOP because each object should have both attributes and behaviors
  • BaseBean: Inheriting functionality from a utility class rather than delegating to it
  • Call super: Requiring subclasses to call a superclass's overridden method
  • Circle-ellipse problem: Subtyping variable-types on the basis of value-subtypes
  • Empty subclass failure: Creating a class that fails the "Empty Subclass Test" by behaving differently from a class derived from it without modifications
  • God object: Concentrating too many functions in a single part of the design (class)
  • Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
  • Object orgy: Failing to properly encapsulate objects permitting unrestricted access to their internals
  • Poltergeists: Objects whose sole purpose is to pass information to another object
  • Sequential coupling: A class that requires its methods to be called in a particular order
  • Singletonitis: The overuse of the singleton pattern
  • Yet Another Useless Layer: Adding unnecessary layers to a program, library or framework. This became popular after the first book on programming patterns.
  • Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

[edit] Programming anti-patterns

  • Accidental complexity: Introducing unnecessary complexity into a solution
  • Accumulate and fire: Setting parameters for subroutines in a collection of global variables
  • Action at a distance: Unexpected interaction between widely separated parts of a system
  • Blind faith: Lack of checking of (a) the correctness of a bug fix or (b) the result of a subroutine
  • Boat anchor: Retaining a part of a system that no longer has any use
  • Bug magnet: A block of code so infrequently invoked/tested that it will most likely fail, or any error-prone construct or practice.
  • Busy spin: Consuming CPU while waiting for something to happen, usually by repeated checking instead of proper messaging
  • Caching failure: Forgetting to reset an error flag when an error has been corrected
  • Cargo cult programming: Using patterns and methods without understanding why
  • Checking type instead of interface: Checking that an object has a specific type when only a certain contract is required. May cause Empty subclass failure.
  • Code momentum: Over-constraining part of a system by repeatedly assuming things about it in other parts
  • Coding by exception: Adding new code to handle each special case as it is recognized
  • Error hiding: Catching an error message before it can be shown to the user and either showing nothing or showing a meaningless message
  • Expection handling: (From Exception + Expect) Using a language's error handling system to implement normal program logic
  • Hard code: Embedding assumptions about the environment of a system at many points in its implementation
  • Lava flow: Retaining undesirable (redundant or low-quality) code because removing it is too expensive or has unpredictable consequences
  • Loop-switch sequence: Encoding a set of sequential steps using a loop over a switch statement
  • Magic numbers: Including unexplained numbers in algorithms
  • 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.
  • Packratting: Consuming excessive memory by keeping dynamically allocated objects alive for longer than they are needed
  • Parallel protectionism: When code becomes so complex and fragile that it is easier to clone a parallel infrastructure than to add a trivial attribute to existing infrastructure
  • Programming by accident: Trying to solve problems by trial and error, sometimes because of poor documentation or not thinking things out first.
  • Ravioli code: Systems with lots of objects that are loosely connected
  • Soft code: Storing business logic in configuration files rather than source code[4]
  • Spaghetti code: Systems whose structure is barely comprehensible, especially because of misuse of code structures
  • Wrapping wool in cotton: Commonly observed when framework methods are contained in single line methods in wrapper classes which provide no useful abstraction

[edit] Methodological anti-patterns

  • Copy and paste programming: Copying (and modifying) existing code rather than creating generic solutions
  • De-factoring: The process of removing functionality and replacing it with documentation
  • Golden hammer: Assuming that a favorite solution is universally applicable (See: Silver Bullet)
  • Improbability factor: Assuming that it is improbable that a known error will occur
  • Low hanging fruit: Dealing with easier issues first while ignoring larger more complex issues. It can be thought of as to the relative ease with which scientific, philosophical and technological discoveries are made at first compared with the difficulties once the subject has already been explored.[clarify]
  • Not built here : See: Reinventing the wheel, Not invented here.
  • Premature optimization: Coding early-on for perceived efficiency, sacrificing good design, maintainability, and sometimes even real-world efficiency
  • Programming by permutation: Trying to approach a solution by successively modifying the code to see if it works
  • Reinventing the square wheel: Creating a poor solution when a good one exists
  • Reinventing the wheel: Failing to adopt an existing, adequate solution
  • Silver bullet: Assuming that a favorite technical solution can solve a larger process or problem
  • Tester driven development: Software projects where new requirements are specified in bug reports

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

[edit] Configuration management anti-patterns

[edit] See also

[edit] References

  1. ^ Budgen, D. (2003). Software design. Harlow, Eng.: Addison-Wesley, pp. 225. ISBN 0-201-72219-4.  "As described in Long (2001), design anti-patterns are 'obvious, but wrong, solutions to recurring problems'."
  2. ^ Ambler, Scott W. (1998). Process patterns: building large-scale systems using object technology. Cambridge, UK: Cambridge University Press, pp. 4. ISBN 0-521-64568-9.  "...common approaches to solving recurring problems that prove to be ineffective. These approaches are called antipatterns."
  3. ^ Koenig, Andrew (March/April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming 8, (1): 46-48. ; was later re-printed in the: Rising, Linda (1998). The patterns handbook: techniques, strategies, and applications. Cambridge, U.K.: Cambridge University Press, pp.387. ISBN 0-521-64818-1.  "Anti-pattern is just like pattern, except that instead of solution it gives something thats looks superficially like a solution, but isn't one."
  4. ^ Soft Coding

[edit] Further reading

  1. Laplante, Phillip A.; Colin J. Neill (2005). Antipatterns: Identification, Refactoring and Management. Auerbach Publications. ISBN 0-8493-2994-9. 
  2. Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Scott W. Thomas, Theresa Hudson (ed). (2000). Anti-Patterns in Project Management. John Wiley & Sons, ltd. ISBN 0-471-36366-9. 

[edit] External links