Design anti-pattern

An design anti-pattern is a design pattern that invariably leads to a bad solution to a problem.

By documenting anti-patterns, in addition to design patterns, arguments are given to system designers not to choose bad paths, based on available documentation rather than just intuition.

The term originates from the book Design Patterns, written by a group of authors known as the Gang of Four, which brings together a set of good programming solutions. The authors baptized these solutions with the name of "design patterns" by analogy with the same term, used in architecture. The book Anti-Patterns (by William Brown, Raphael Malveau, Skip McCormick and Tom Mowbray, along with the more recent addition of Scott Thomas) describes anti-patterns as the natural counterpart to the study of design patterns.. The formal study of repeated errors makes it possible to recognize and redirect the elements involved towards a better solution. Anti-patterns are not mentioned in the original Design Patterns book, since this one is earlier.

Anti-patterns are considered an important part of good programming practice. That is, a good programmer will try to avoid anti-patterns whenever possible, which requires their recognition and identification as early as possible in the software life cycle.

The concept of anti-pattern can be applied to engineering in general, and even to any task performed by man. Although not often heard outside of the engineering field, the notion is widespread.

Some software development anti-patterns

Project Management Antipatterns

• Smoke and mirrors (smoke and mirrors): Show how it will be functionality before it is implemented.
• Poor management (bad management): Manage a project without having sufficient knowledge about it.
• Inflated software (software bloat): Allow the successive versions of a system to increasingly require resources.

General anti-patterns of software design

• Database as a process communicator (database as an IPC): Using a database to communicate processes on one or more computers, when communication between direct processes is more appropriate.
• Blob: See All-Powerful Object.
• BOMQ (Batch Over MQ): Abuse in the use of integration based on real-time messages for large-scale sporadic transfers in the background.
• Fatty class: To give a class with too many attributes and/or methods, making it responsible for most of the business logic.
• Magical button (magic pushbutton): Tender, developing interfaces, to program the business logic in the methods of interaction, implementing the results of user actions in terms not abstract enough.
• Race of obstacles (race hazard): Inability to foresee the consequences of different events.
• Entry in the middle (input kludge): Do not specify and implement the handling of invalid entries.
• Fuel Factory (gas factory): Unnecessarily complex design.
• Big mud ball (big ball of mud): Build a system without defined structure.
• Inflated interface (interface bloat): To pretend that an interface is so powerful that it is extremely difficult to implement.
• Abstraction investment (abstraction inversion): Do not expose the implemented functionalities that users need, forcing them to reimplement at a higher level.
• Ambiguous point of view (ambiguous viewpoint): To present a model without specifying certain aspects, thus deferring conflicting decisions.
• Re-dependence (re-coupling): Introduce unnecessary units between objects.
• Heating pipe system (stovepipe system): Build a system that is difficult to maintain, assembling unrelated components.
• Safety by obscation: Generate systems that hide or make the operation of the components in the input, in response or in errors against intuitive. Turning development tools or services into magic boxes.
• Continuous dependent integration: Perform control processes for each step of development that depend on the validation of third parties by generating a constant dependency among all the development groups involved.

Anti-patterns of object-oriented design

• Sequential coupling (sequential coupling): Build a class that needs its methods to be invoked in a given order.
• BaseBean: To inherit functionality of a useful class instead of delegating it.
• Empty-class failure (empty subclass failure): Creating a class that does not exceed empty subclass test, that is, it behaves differently when invoked from a subclass that does not add any modification.
• Call super (call): Force the subclasses to call a superclass method that has been overwritten.
• Anamic Domain Model (anemic domain model): Use a domain model without any business logic. This is not an object-oriented approach because each object should have both properties and associated behavior.
• Sumitable object (swimming object)object cesspool): Reuse objects not really suitable for the purpose being pursued.
• All-powerful object (god object): Focus too much functionality on a single part of the design (class).
• Poltergeist (informatics): Use objects whose sole purpose is to pass the information to third objects.
• Circle-elipse problem (circle-ellipse problem): Create type variables thinking about the values of possible subtypes.
• Yoyó problem (I-I problem.): Build structures (e.g. inheritance) that are difficult to understand because of their excessive fragmentation.
• Singletonitis: Abuse of singleton pattern use.
• YAFL (yet another fucking layer, and another damn layer more) or 'Lasagna Code': Add unnecessary layers to a program, library or framework. This trend spread well after the first book on patterns was published.

Programming Antipatterns

• Heroic nomenclature (heroic naming): Identify the members of a program (interfaces, classes, properties, methods...) with names that cause the apparent set of standardization with the engineering of the software but that actually conceals an anarchic implementation.
• Remote action (action at a distance): Provoking the unforeseen interaction of components very distant from a system.
• Accumulate and shoot (accumulate and fire): Establish a collection of global variables to be used by a set of subroutines.
• Boat anchor (boat anchor): To retain parts of the system that are no longer useful.
• Active loop (busy spin): Using active wait when alternatives exist.
• Hard code (hard code): Make assumptions about the system environment in too many places of implementation.
• Unnecessary Complexity (non-inclusive)accidental complexity): Provide unnecessary complexity to a solution.
• Spaghetti code (spaghetti code): Building systems that are difficult to understand, especially due to the low use of programming structures.
• Ravioli code (ravioli code): Build systems with a multitude of objects very weakly connected.
• Checking types instead of interface (checking type instead of interface): To verify that an object is of a specific type when the only thing that is needed is to verify whether it meets a particular contract.
• Blind trust (Blind trust)blind faith): Discuss the check of the results produced by a subroutine, or the effectiveness of a patch or solution to a problem.
• Double Locking Check (double-checked locking): Check, before modifying an object, if necessary make that modification, but not blocked to check it, so that such check may fail.
• Cache failure (caching failure): Forget to restore a mark of error when it has already been treated.
• Dry washing (dry washing)lava flow): Dead code and forgotten design information remain frozen in a changing design. This is analogous to a lava flow in which rock pieces are hardened. The solution includes a configuration management process that eliminates the dead code and allows to evolve or remake the design to increase quality.
• Super-boolean logic (superboolean logic): Use unnecessary comparisons or abstractions of boolean logic.
• Handling of exceptions (exception handling): Use the language exception management mechanism to implement the overall logic of the program.
• Management of useless exceptions (exception useless handling): Introduce conditions to prevent exceptions in execution time, but manually release an exception if such condition fails.
• Time of code (code momentum): Set too many restrictions on a part of the system due to the assumption of many of its properties from other parts of the system itself.
• Magical numbers (magic numbers): Include in concrete algorithms numbers without apparent explanation.
• Mistake concealment (error hiding): Capture an error before the user is shown, and replace it with an unimportant message or message at all.
• Packratting: Consuming memory in excess because you do not release objects dynamically reserved once you have ceased to be necessary.
• Programme by exception (coding by exception): Add bits of code to treat special cases as they are identified.
• Loop sequence by case (Loop-switch sequence): Schedule a set of sequential steps using a loop in combination with a case control structure.
• Magic chains (magic strings): Include specified character strings in the source code to make comparisons, such as event types, etc.
• Code ñoqui (gnocchi code): Include code that doesn't really do anything or contribute to the system. The name refers to an Argentine holiday called Ñoqui Day day or period (end of month) in which, employees who do nothing (usually state) will charge.

Methodological antipatterns

• Silver bullet (silver bullet): Assuming that our favorite technical solution can solve a much greater problem.
• Evidence-driven development (tester driven development): Allow a software project to advance based on extracting its new requirements from error reports.
• Defactory (de-factoring): Remove functionality and replace it with documentation.
• Improbability factor (improbability factor): Assuming that it is unlikely that a known error causes real problems.
• Gold hammer (golden hammer): Assuming that our favorite solution is universally applicable, making good the saying to a hammer, everything is nails.
• Premature optimization (premature optimization): Perform optimizations without having sufficient information to do so with guarantees, sacrificing design decisions.
• Programming to copy and paste (copy and paste programming): Schedule copying and modifying existing code rather than creating generic solutions.
• Permutation programme (programming by permutation): Try to approach a solution by modifying the code over and over again to see if it ends up working.
• Reinventing the wheel (reinventing the wheel): Face situations by seeking solutions from scratch, without taking into account others that may already exist to deal with the same problems.
• Reinvent the square wheel (reinventing the square wheel): Create a poor solution when there is already a good one.

Configuration management anti-patterns

• Conflict of extensions (extension conflict): Problems with different extensions that try to manage the same parts of the system (specific Mac OS).
• Inferno of units (dependency hell): Scenario of problems produced by versions of other products that are needed to operate a third party.
  • Infierno DLL (infierno DLL)DLL): Problems with versions, availability or proliferation of DLLs (soft Windows specific)
  • Infierno JAR (JAR hell): Problems with different versions or locations of JAR (Java) files, typically caused by the lack of understanding of the class load model.

Some organizational anti-patterns

• Incremental scope (increasing range)scope creep): Allow the scope of a project to grow without proper control.
• Supplier Unit (Lock-in vendor): Build a system that is overly dependent on a component provided by a third party.
• Committee design (design by committee): Count with many opinions on a design, but boast of a lack of unified vision.
• Scale of engagement (escalation of commitment): Not being able to revoke a decision in view of the fact that it has not been successful.
• Growing functioning (creeping featuritis): Add new functionalities to the system to the detriment of its quality.
• Number-based management (management by numbers): Paying too much attention to quantitative management criteria, when they are not essential or difficult to meet.
• Mushroom management (mushroom management): Treat employees without looking, without informing them of decisions that affect them (maintaining them covered and in the dark, like mushrooms).
• Management because I say so (management by perkele): Apply authoritarian management with null tolerance to dissent.
• Cost migration (cost migration): Transfer the costs of a project to a vulnerable department or business partner.
• Continuous obsolescence (continuous obsolescence): To devote disproportionate efforts to adapt a system to new environments.
• Organization of violin rope (violin string organization): Maintain a refined and in good condition, but without any flexibility.
• Analysis paralysis (analysis paralysis): Dedicate disproportionate efforts to the phase of analysis of a project, eternizing the iterating design process on the search for better solutions or variants.
• Moral dangermorale): Isolate who has made a decision following the consequences of it.
• pipe system (stovepipe): Having a structured organization so that it favors the flow of vertical information, but inhibits horizontal communication.
• I told you.I told you so): Allowing attention to focus on the disobedience of an expert has been justified.
• Gold Egg Gallina (Golden Eggs)cash cow): Pecar de autocomplacencia versus new products for having a product legacy Very lucrative.

Alphabetical list of other antipatterns

• Throw to the other side of the wall (thrown over the wall): When a project involves several working groups and goes sequentially from one to another, with little or no communication between them.
• Wolf Ticket (wolf ticket): Declaring compatibility with a standard when it does not exist, or when the standard only includes non-mandatory recommendations that, in fact, are not followed.
• Feast of the mouths (Blowhard Jamboree): When the technical decisions of the project are intended to be based on opinions experts published in the press.
• Chain without length (string without length).
• Waterfall dialog boxes (cascading dialog boxes).
• Outputless alley (dead end): Finding a problem that prevents continuing to work, but management does not allow to correct the problem. The team's stuck.
• Walk through a minefield (walking through a mine field): Working with a poorly proven (usually unstable) component, and therefore unreliable.
• scapegoat (scape goat): In the circumstances of crisis in a project the decision is made to direct the blame to a person or to a group of concrete people without analyzing whether the nature of the problem is in them.
• Brutal coding: Press programmers to work on an architecture without design and without obvious requirements.
• Designated Committee (appointed team): Create a committee or working group to resolve a problem and not deal with making the group work.
• Equitable compensation (e)egalitarian compensation): Compensate the staff for the individual work done.
• Magic container (magic container): The implementation of methods that attempt to be as flexible as to adapt their behavior to a multitude of circumstances, surpassing the threshold of proper maintenance.
• Tibian bodies (warm bodies).
• Worship to the freighter (position hidden): It consists in copying certain practices that could be considered (not always) good practices without knowing very well the benefits or advantages they provide, causing unnecessary effort in the project to incorporate them or problems.
• Culture of fear (fear culture)): Environment in which every employee is afraid to show the result of his work for fear of being fired for having mistakes.
• Hero culture (hero culture): It occurs when one or few people take responsibility for the success of the entire team or project, often working on time.
• Arithmetic Decisiondecision by arithmetic): Instead of trying to make a decision with the available data and based on the knowledge and experience of our collaborators and ours, it is a matter of justifying it on the basis of supposedly objective factors.
• Geographically distributed developmentgeographically distributed development).
• Development marked by tools (autogenerated stovepipe): Prefer an automatically generated solution on the best solution.
• Functional decomposition (functional decomposition)functional decomposition): Translate a structured language program to an OO using one class and many private methods.
• Design for design (design for the sake of design): Perform excessively complex design without real necessity.
• Design with architecture imposed (architecture as requirement): To suppose that the design necessarily considers the use of tools or methods not necessarily suitable.
• Sink design (kitchen sink design).
• Empirical designers (architects don't code): Inability of the design group to assess the complexity of the designed object.
• E-mail is dangerous (email is dangerous): Danger to forget that behind the emails received there are people of flesh and blood.
• The manager controls the process (manager controls process).
• The new costume of the emperor (emperor's new clothes): Fear of pointing out the defects of a product or process that a manager or manager believes works well.
• The Old Big Duke of York (the grand old Duke of York): When architects or analysts do not intervene (one or both), leaving programmers (specialists in implementation) virtually all decisions at the level and execution of the user specifications.
• They understood me.They understood me): Explain to junior programmers or designers what is expected of them very briefly, and assume that they understood what was asked of them.
• Award of exceptions (exception funnel): Catch an exception and ignore it, without reporting it.
• Train the coach (train the trainer): Hiring a training without having accurately specified the matter on which it is desired. This may cause training to not be properly approached, dealing with aspects that are not necessary in the project or leaving out fundamental aspects. Recruiting a training without having any references from the trainer, as the same level of knowledge is not adequate to the nature of the training to impart.
• It is an operator problem (it is an operator problem).
• Hide the weapons (cover your assets).
• False economy (false economy): Allowing budget cuts to affect worker efficiency (loss end up being greater than saved).
• False final point subrogated (false surrogate endpoint).
• Dates in floating point (floating point times).
• Make your own database (roll your own database): In view of the need for persistence of data, a solution is used that is not based on a standard.
• Supported and interchangeable engineers (plug compatible interchangeable engineers).
• Introduction of difficulty by analogy (analogy breakdown): Design by analogy with solved problems, possibly introducing difficulties not inherent to the problem, or neglecting difficulties inherent in the new case being handled.
• Invoke builders with nulls (passing nulls to builders).
• The family dispute (the feud): When there is a conflict between project managers, a definitive solution is not sought.
• Experience kills design (architecture by implication): Declining the design by relying excessively on previous experience.
• Customers are fools (customers are idioms): To think that one knows more than the client, and therefore there is no need for research with the client.
• Control maniac (control freak): The desire for control leads to micromanagement and this in turn to a significant loss of the ability to self-manage the equipment, since all steps are millimetrically measured.
• Rube Goldberg Machine (Rube Goldberg machine): Make very complex implementations for simple tasks.
• Kill the messenger (shoot the messenger).
• Kill two birds with one shot (kill two birds with one stone).
• Extreme marriage (sumo marriage): It happens in any situation where there is a dependence on an element or a number of factors that hinder the maintenance or evolution of the system.
• Maize Mazorca (corn cob): Keep people in the project that are difficult, conflictive or that work absolutely outside of what is any teamwork or solidarity behavior and that break with the harmony of the group.
• Discordant reward mechanisms (discordant reward mechanisms): A team is recognized as the one that performs the most on the basis of objective criteria that are not valid to measure the level of productivity or quality.
• Software mixer (software).
• Fear of success (fear of success): Allow the only reasons that work is not completed to be social.
• Coin in floating point (floating point currency): Using a floating point representation for values that represent money, which can cause loss of precision.
• To die planning (death by planning): Investing more effort (and time) than necessary to establish a plan that can then be destroyed by the development process's own contingencies, or when it is not flexible in the face of initial planning, staying along the project despite the fact that it is absolutely unreal.
• Nationalism (national ism).
• Swiss Navaja (swiss army knife): Try to create a product that solves several unrelated problems.
• It's not my job.Not my job): Do not solve any obvious problem by arguing that it is another problem or fault.
• Not specifying (specify nothing).
• Not invented here (not invented here): When the organization or one refuses to use solutions, methodologies, practices, tools, etc. external only because it did not occur to us previously.
• Another meeting will resolve it (yet another meeting will solve it): In the face of a problem in project planning, meetings are convened to try to solve the problem. These meetings involve the members of the project team who will have to leave their usual work, resulting in further delays.
• Another more programmer (yet another programmer).
• Presumed heir (heir apparent): When we see that the possible gaps that could remain to further progress in our organization have already names and surnames (when their merits are more than debatable), it will cause the organization to leave in search of other alternatives or a loss of motivation that will directly impact productivity.
• Idiot-proof process (idio proof process).
• Discordant programmer (net negative producing programmer): There are projects where the performance of one or more team members is much lower than expected, to the point of being their net productivity in the negative project (the project would improve with the simple fact of dispensing these people, without the need to replace them with another)
• Marmota day project (ground hog day project): Discuss the same topics in all meetings, just to conclude that "something must be done."
• Incomplete test (asynchronous unit testing): Discuss in the test stage, some units in all cases, or all units in some cases.
• I want estimates now (give me estimates now): Give estimates without having enough data to do them.
• Requirements scattered over the wall (requirements tossed over the wall): There is a general disorder in the requirements: they are in different degrees of termination, there is no prioritization of them or it is very general to be able to make proper management by that criterion, etc. This is usually caused by inadequate collaboration on the part of the user area.
• Hidden requirements (Hidden requirements): The project team aware of the difficulty of implementing a certain requirement makes it obvious within the requirements catalog, assigns it a very low priority or encompasses it within a higher level requirement that is difuted in it. The user area does not specify a requirement or does not specify it properly, requesting later explanations for the non-implementation of that requirement or for its incorrect behavior.
• If it works, don't touch it (if it is working don't change): Developments are based on non-functioning needs. If it is necessary to adapt to a new need it will be necessary to change something that works, or eliminate it completely, to get the expected results. Adding new functionality while maintaining the previous one involves new problems, such as lasagna code, dry lava or clay anchor.
• We are fools (we are idiots): To think that the internal knowledge of the problem is dangerous (at the risk that it is poor or wrong), and to ask for validation of the client for each major feature or decision.
• CRCI Cards (CRCC)CRCI cards): When using the CRC card technique, it is used and included in the same the implementation of the class, automatically becoming the CRC card (Class-Responsibility-Collaboration) in CRCI (Class-Responsibility-Collaboration-Implementation).
• Refuses storm (blame storming): A project team concludes that the best way to analyze the causes of the failure to achieve the objectives is to discuss who has been guilty internally.
• Voodoo tower (tower of voodoo):You have a code that is known to work (although it is generally not well known how) and it is intended to add some type of additional functionality, sometimes not very cohesive with the already implemented and you are placed a wrapper (wrapper) providing a new interface of access to that new component.
• Bears Trap (Oose Trap)Bear rag): Investing a lot in an unsuitable or feasible tool, so it is then impossible to get rid of it.
• Unique function output point (single function exit point).
• Undefined default value (zero means null): Choose an arbitrary value to represent indefinition, without guaranteeing that that value cannot really happen.
• Intellectual violenceintellectual violence): Internally in a working team or in a meeting with the client and/or with users, terms are used, generally technical, which are not understood or known by most interlocutors.