anti-pattern
Social and business operations
Organizational
A project that has stalled in the analysis phase of development, and is unable to achieve support for any of the potential plans of its implementation
Giving disproportionate weight to trivial issues
Operating with cutting-edge technologies that are still untested or unstable, leading to cost overruns, under-performance or delayed delivery of the product
The phenomenon in which people are less likely to or do not offer help to a person in need when others are present
A profitable legacy product that often leads to complacency about new products
The result of having many contributors to a design, but no unifying vision
Failing to revoke a decision when it proves wrong
A collective state where group members begin, often unknowingly, to think alike and reject differing viewpoints
Management operating with the exclusive focus on quantitative management criteria, such as number of sales, when these are non-essential or cost too much to acquire
Ineffective results stemming from excessive observation, supervision, or other hands-on involvement from management
Insulating a decision-maker from the consequences of their decision
Keeping employees "in the dark and fed manure" (also "left to stew and finally canned") about decisions being taken by management
Continually promoting otherwise well-performing employees up to a position they are unsuited for, with responsibilities they are incompetent at completing, where they remain indefinitely
Management in which managers only interact with employees when a problem arises, when they "fly in, make a lot of noise, dump on everyone, do not solve the problem, then fly out"
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
Locking successful employees into overly-safe, narrowly defined, predictable roles based on their past successes rather than their potential
Making a system excessively dependent on an externally supplied component
Project management
Focusing too many resources on a stage of a project out of its sequence
A project whose staff, while expecting it to fail, are compelled to continue, often with much overwork, by management in denial of the project's possible failure
Tendency to underestimate the amount of time to complete a project when it is "nearly done"
Spending resources making a project more robust and complex than is needed
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)
Demonstrating unimplemented functions as if they were already implemented
Adding more resources to a project to increase velocity, when the project is already slowed by coordination overhead
Continuing to work on a task or project well past the point at which extra effort is not adding value
Software engineering
Software design
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
Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
A system with no recognizable structure
Using a database as the message queue for routine interprocess communication where a much more lightweight mechanism would be suitable
A system so customizable as to become a poor replica of the software development platform
Failing to specify and implement the handling of possibly invalid input
Making an interface so powerful that it is extremely difficult to implement
A form with no dynamic validation or input assistance, such as dropdowns
Failing to see the consequences of events that can sometimes interfere with each other
A barely maintainable assemblage of ill-related components
Object-oriented programming
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.
Requiring subclasses to call a superclass's overridden method
Subtyping variable-types on the basis of value-subtypes
Introducing unnecessary direct or indirect mutual dependencies between objects or software modules
Using interfaces to define constants
Concentrating too many functions in a single part of the design (class)
Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
Failing to properly encapsulate objects permitting unrestricted access to their internals
Objects whose sole purpose is to pass information to another object
A class that requires its methods to be called in a particular order
This design pattern brings coupling and is considered a bad solution
A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation
Programming
Programming tasks which could be eliminated with better tools (as opposed to essential complexity inherent in the problem being solved)
Unexpected interaction between widely separated parts of a system
Retaining a part of a system that no longer has any use
Consuming CPU while waiting for something to happen, usually by repeated checking instead of messaging
Forgetting to clear a cache that holds a negative result (error) after the error condition has been corrected
Using patterns and methods without understanding why
Adding new code to handle each special case as it is recognized
The use of patterns has itself been called an anti-pattern, a sign that a system is not employing enough abstraction
Catching an error message before it can be shown to the user and either showing nothing or showing a meaningless message. This anti-pattern is also named Diaper Pattern. Also can refer to erasing the Stack trace during exception handling, which can hamper debugging.
Embedding assumptions about the environment of a system in its implementation
Programs whose structure consists of too many layers of inheritance
Retaining undesirable (redundant or low-quality) code because removing it is too expensive or has unpredictable consequences
Encoding a set of sequential steps using a switch within a loop statement
Including unexplained numbers in algorithms
Implementing presumably unlikely input scenarios, such as comparisons with very specific strings, to mask functionality.
Writing code which contains repetitive patterns and substrings over again; avoid with once and only once (abstraction principle)
Throwing exceptions from the scope of a plugin or subscriber in response to legitimate input, especially when this causes the outer scope to fail.
Developer adds features to an application codebase which span a multiplicity of implementors or implementations in a single change
Storing business logic in configuration files rather than source code
Programs whose structure is barely comprehensible, especially because of misuse of code structures
Methodological
Copying (and modifying) existing code rather than creating generic solutions
Assuming that a favorite solution is universally applicable (See: Silver bullet)
The tendency towards dismissing any innovation or less than trivial solution originating from inside the organization, usually because of lack of confidence in the staff
The tendency towards reinventing the wheel (failing to adopt an existing, adequate solution)
Coding early-on for perceived efficiency, sacrificing good design, maintainability, and sometimes even real-world efficiency
Trying to approach a solution by successively modifying the code to see if it works
Failing to adopt an existing solution and instead adopting a custom solution which performs much worse than the existing one
Assuming that a favorite technical solution can solve a larger process or problem
Software projects in which new requirements are specified in bug reports
Configuration management
Problems with versions of required products
Inadequate management of dynamic-link libraries (DLLs), specifically on Microsoft Windows
Problems with different extensions to classic Mac OS attempting to patch the same parts of the operating system
Overutilization of multiple JAR files, usually causing versioning and location problems because of misunderstanding of the Java class loading model
List of software development philosophies – approaches, styles, maxims and philosophies for software development
List of tools for static code analysis
ISO/IEC 29110: Software Life Cycle Profiles and Guidelines for Very Small Entities (VSEs) ? (AntiPattern|anti pattern)