Anti-Patterns in Programming: Development, Managerial, Architectural

An anti-pattern is a widespread approach to solving a class of frequently encountered problems that turns out to be ineffective, risky or counterproductive. Unlike a design pattern, the description of an anti-pattern covers both the wrong solution — with its symptoms and consequences — and the way out of the situation.

The term comes from computer science, from the «Gang of Four» book «Design Patterns», which laid down examples of good programming practice. The authors called these good techniques «patterns», and their opposites are «anti-patterns».

Anti-patterns are conceptually similar to patterns in that they document recurring solutions to common problems. They are known as anti-patterns because their use (or misuse) produces negative consequences

History

As the IT industry developed, the scale of software projects and the resources they consumed grew rapidly, which gave rise to a large number of problems facing programmers. Most of these problems were typical and occurred in almost every large project. In the early 1990s, catalogues of design patterns — elegant, practice-proven ways of solving typical tasks — gained considerable popularity. Patterns remain powerful and extremely popular to this day, yet many developers, applying popular patterns in situations they were not intended for, created more problems than they solved. In addition, IT engineers, like workers in any other field, make a set of typical mistakes caused by an insufficient knowledge base or lack of experience, haste and pressure from project deadlines, financial constraints and so on.

The term «anti-pattern», in the sense of a generalised description of a typical failed solution, was first used in 1996 by Michael Akroyd at the «Object World West Conference», devoted to aspects of object-oriented programming. In his presentation «Antipatterns: Preventing Object Misuse», Akroyd drew attention to harmful but common programming constructs, in particular those that contradict OOP principles. Moreover, for each such construct he proposed an effective replacement.

The term in the sense of «a bad idea» had appeared before Akroyd, but it was not published and enjoyed no particular popularity. Even so, authorship should not be attributed to a single person. According to William Brown, author of the book «AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis», an anti-pattern is a stage in the evolution of the design pattern concept, an extension of its model.

How to recognise an anti-pattern

An anti-pattern usually has 4 traits:

Example:

Classification of anti-patterns

William Brown distinguishes anti-patterns from three points of view: the developer, the architect and the manager:

• Development antipatterns
• Architectural antipatterns
• Managerial antipatterns

Neill and Laplante add a fourth type:

• Environmental antipatterns

In addition, anti-patterns have been described for individual information technologies, such as:

• information security
• code reuse
• human-computer interaction
• service-oriented architecture
• intelligent information systems

Development anti-patterns

Technical problems and solutions that programmers deal with:

Anti-patterns in object-oriented programming

• BaseBean: Inheriting functionality from a utility class instead of delegating to it.
• Anemic Domain Model — a fear of placing logic in domain objects.
• Call super : To implement application functionality, a method of a descendant class is required to call the same methods of the ancestor class.
• Empty subclass failure: Creating a class (in Perl) that fails the «Empty Subclass Test» because it behaves differently from a class that inherits from it without changes.
• God object: Concentrating too much functionality in a single part of the system (class).
• Object cesspool: Reusing objects that are in a state unfit for reuse.
• Poltergeist : Objects whose only purpose is to pass information to other objects.
• Yo-yo problem^[en]: Excessive dispersal of tightly coupled code (for example, code executed in sequence) across a class hierarchy.
• Singletonitis: Inappropriate use of the singleton pattern.
• Friend zone: Inappropriate use of friend classes and friend functions in C++.
• Interface soup: Merging several interfaces, separated according to the interface segregation principle, back into one.
• Loose ends: An interface most of whose methods are meaningless and are implemented as stubs.
• Stub: Trying to force an existing, semantically ill-fitting interface onto an object instead of creating a new one.

Anti-patterns in writing code

• Accidental complexity : Introducing unnecessary complexity into a solution.
• Action at a distance : Unexpected interaction between widely separated parts of a system.
• Accumulate and fire: Setting subroutine parameters in a set of global variables.
• Blind faith : Insufficient verification of the correctness of a bug fix or of a subroutine's result.
• Boat anchor : Keeping a part of the system that is no longer used.
• Busy spin, busy waiting : Consuming CPU resources (processor time) while waiting for an event, usually by means of a constantly repeated check, instead of using asynchronous programming (for example, a message or event system).
• Caching failure : Forgetting to reset an error flag after handling the error.
• The Diaper Pattern Stinks: Clearing an error flag without handling the error or passing it to a higher-level handler.
• Checking type instead of membership, Checking type instead of interface: Checking that an object has a specific type when only a certain interface is required.
• Code momentum: Over-constraining a part of the system by constantly assuming its behaviour in other parts of the system.
• Coding by exception : Adding new code to support each special case as it is discovered.
• Cryptic code: Using abbreviations instead of mnemonic names.
• Hard code: Embedding assumptions about the system's environment in too many points of its implementation.
• Soft code: A pathological fear of hard-coding, leading to everything being made configurable, so that configuring the system itself turns into programming.
• Lava flow : Keeping unwanted (redundant or low-quality) code because removing it is too expensive or would have unpredictable consequences.
• Magic numbers: Using numeric constants without explaining their meaning.
• Procedural code: When another paradigm would be more suitable.
• Spaghetti code: Code with an excessively tangled flow of execution.
• Lasagna code (also called «onion»): Excessive coupling between abstraction layers, making it impossible to change one layer without changing the rest.
• Ravioli code: Objects so «glued» together that they are practically impossible to refactor.
• Soap bubble: An object initialised with garbage that pretends for as long as possible that it contains some data.
• Mutex hell: Introducing too many synchronisation objects between threads.
• (Meta-)template cancer: Pervasive use of templates (mainly in C++), including where their use is not justified. This reduces code comprehension and maintainability and slows down compilation.

Methodological anti-patterns

• Copy and paste programming: Copying (and lightly modifying) existing code instead of creating shared solutions.
• De-Factoring: The process of destroying functionality and replacing it with documentation.
• Golden hammer: A strong belief that a favourite solution is universally applicable. The name comes from the saying «when all you have is a hammer, every problem looks like a nail».
• Improbability factor: Assuming that a known bug cannot possibly be triggered.
• Premature optimization: Optimising a code segment at the design stage, making it more complicated or distorted.
• Programming by permutation: An approach to software development through small trial-and-error changes.
• Reinventing the wheel: Building from scratch instead of using a good existing solution.
• Reinventing the square wheel: Creating a poor solution when a known better one already exists.
• Self-destruction: A fatal error or non-standard program behaviour leading to denial of service, caused by another, less serious error. For example, when an error occurs the application starts writing to the log very fast and very heavily, so that disk space runs out before monitoring detects it.
• Two tunnels: Moving new functionality into a separate application instead of extending the existing one. It is most often applied when, for whatever reason (usually lack of time or management's reluctance), making changes to the existing code costs more than building something new. As a result, the customer ends up running two applications, launched simultaneously or alternately from one another.
• Commit assassin: Committing individual changes to version control without checking their impact on other parts of the program. As a rule, after such commits the team's work is paralysed while problems are fixed in places that previously worked flawlessly.

Configuration management anti-patterns

• Dependency hell (on the Microsoft Windows platform also called «DLL hell»): The growth of the graph of mutual dependencies between software products and libraries, making it difficult to install new products and remove old ones. In complicated cases, different installed software products require different versions of the same library. In the most complicated cases, a single product may indirectly require two versions of the same library at once.

Miscellaneous

• Smoke and mirrors: Demonstrating what unwritten features will look like (the name comes from two favourite ways magicians conceal their secrets).
• Software bloat: Allowing successive versions of a system to require more and more resources.
• Checkbox features: Turning a program into a conglomerate of poorly implemented and unrelated features (usually so that the advertising can claim the feature exists).

Architectural anti-patterns

Typical problems related to the structure of systems:

• Abstraction inversion: Hiding part of the functionality from external use in the hope that no one will need it.
• Ambiguous viewpoint: Presenting a model without specifying the viewpoint from which it is considered.
• Big ball of mud: A system with no discernible structure.
• Blob: see God object.
• Gas factory: Unnecessary design complexity.
• Input kludge: Forgetting to specify and implement support for possible invalid input.
• Interface bloat: Designing an interface that is very powerful and very difficult to implement.
• Magic pushbutton: Implementing the results of user actions through an unsuitable (insufficiently abstract) interface. For example, in Delphi-style systems this means writing application logic inside button-click handlers.
• Re-Coupling: The process of introducing an unnecessary dependency.
• Stovepipe System: A rarely maintained assembly of poorly connected components.
• Race hazard, race condition: Failing to anticipate that events may occur in an order other than the expected one.
• Mutilation: Excessively «sharpening» an object for one very narrow task in such a way that it becomes incapable of handling any other task, even a very similar one.
• Save or die: Writing configuration changes to disk only when the application shuts down; as a result, if the program fails, this data is lost
• Architecture by implication: This anti-pattern is characterised by the absence of architectural specifications for the system being developed. As a rule, the architects responsible for the project have experience building previous systems and, relying on their competence and experience, believe that documentation is unnecessary. This overconfidence aggravates risks in key areas affecting the system's success. The lack of architectural definitions is observed in one or more of the following areas:
• Accidental architecture — a situation in which a software system's architecture emerges not as the result of a deliberately conceived and designed decision, but as a by-product of many local, particular decisions made during development. Intentional architecture is created consciously: an architect or team formulates the principles, layers and interactions and implements them. Accidental architecture arises spontaneously: developers solve tasks as they come in, and the resulting structure of the system forms «by itself» out of those decisions.

• Architecture sinkhole: If a request to a service with a layered architecture has to pass through all the layers without any business logic being applied, this indicates the «architecture sinkhole» anti-pattern. This pattern occurs frequently. A normal ratio is 80%–20%; up to 20% of requests exhibiting the «sinkhole» anti-pattern is considered normal.

Managerial anti-patterns

Problems encountered by managers (or groups of managers):

• Analysis paralysis: Unjustifiably large expenditure on analysis and design. Often leads to the project being shut down before implementation even begins.
• Cash cow: When a product brings in profit without substantial investment, no funds are put into developing and building new products.
• Continuous obsolescence: Devoting a disproportionately large effort to porting the system to new environments.
• Cost migration: Shifting a project's costs onto a weaker department or business partner.
• Creeping featurism: Adding new improvements at the expense of the system's overall quality.
• Creeping elegance: Disproportionately improving the beauty of the code at the expense of functionality and the system's overall quality.
• Design by committee: Developing a project without centralised control or competent leadership.
• Escalation of commitment: Continuing to implement a decision after it has been proven wrong.
• I told you so: Ignoring an expert's opinion.
• Management by numbers: Excessive attention to numerical indicators that relate only very indirectly to the system being managed, are difficult to obtain, or are subject to Goodhart's law.
• Management by perkele: An unjustifiably harsh management style.
• Mushroom management: Insufficiently informing employees about the work being done.
• Scope creep: Losing control over the growth of a project.
• Vendor lock-in: Rigid dependence on a supplier.
• Warm Bodies: A person whose contribution to the project is questionable.
• Single head of knowledge (SHOK): When information or skills vital to the project are held by only one person on the team, and work stops when that person leaves.
• Knight in shining armor (KISA): When someone appears on the scene who tries to fix everything without telling anyone what he did or why.

Neill and Laplante list the following anti-patterns:

• Absentee Manager: The manager behaves evasively or is invisible for long stretches of time — hiding somewhere in the office or away from it.
• All You Have Is A Hammer: One-dimensional management, where the same techniques are used on all subordinates and in all situations. Sometimes also called «One-Trick Pony».
• Cage Match Negotiator: Any manager who is stubborn beyond reason and uses a «win at any cost» or «I'm right and you're not» approach to management. They often have a coffee mug with the «Rules of Management»: «Rule #1: The boss is always right. Rule #2: If the boss is wrong, see Rule #1».
• Doppelganger: A manager or colleague who is easy to work with one moment and difficult the next.
• Fruitless Hoops: You prepare more and more data for the managers, data they need in order to make a decision, but the managers never make any decision and keep asking you for more data. You have no idea why they need it.
• Golden Child: The «Golden Child» appears in situations where a manager grants special responsibility, opportunity, recognition or reward to a member of the team based on a personal relationship rather than on that person's actual performance. Everyone is annoyed by the «Golden Child», but the real problem is the manager.
• Headless Chicken: A manager with no focus and no plan, who never finishes anything.
• Leader Not Manager: Emphasises the importance of effective leadership.
• Managerial Cloning: Middle managers who over time start behaving like their own bosses.
• Manager Not Leader: Such a manager handles administrative and managerial duties well but lacks leadership ability.
• Metric Abuse: Misusing metrics through incompetence or deliberate manipulation of the data.
• Mr. Nice Guy: A manager who focuses on being everyone's friend ends up disappointing everyone and failing at his responsibilities.
• Mushroom Management: A situation in which management is unable to communicate effectively with staff. In essence, information is deliberately withheld to keep everyone «fat, dumb and happy». The name comes from an analogy: mushrooms are grown in the dark and in manure.
• Plate Spinning: A manager hides his own ineffectiveness by keeping workers busy with laborious and useless work.
• Proletariat Hero: The manager treats subordinates as if they were ideal workers, but this is merely a prop used to mask poor management. It is a form of staff «motivation» that gives management an excuse to raise expected results or get more for less.
• Rising Upstart: Superstars who cannot spare the time to learn and find their place. Sometimes this stems from ignorance (they don't know what they don't know), and sometimes from impatience (they know what others don't). Such an upstart is a real challenge for all but the most experienced managers.
• Road to Nowhere: The absence of a plan causes confusion and a crisis of leadership.
• Spineless Executive: Any manager who lacks the courage to enter a necessary confrontation or handle a difficult situation. Instead, he avoids the confrontation or situation entirely, or asks you to deliver the bad news for him.
• Three-Headed Knight: An indecisive manager.
• Ultimate Weapon: The manager declares that everyone can rely on the outstanding employees to such an extent that those employees become the conduit for everything.
• Warm Bodies: A management situation in which a worker who barely meets the minimum requirements is moved from project to project or from team to team. The weak worker is called a «warm body», although the real problem is the manager. This anti-pattern is the opposite of «Rising Upstart» in terms of skills and potential.

Environmental anti-patterns

Problems caused by the structure dominant in an organisation and by the social model that results from the organisation's prevailing internal politics

• Ant Colony — beneath an outward beauty lies the imposition of goals
• Atlas Shrug — after a temporary success, decline sets in
• Autonomous Collective — self-governance leads to passivity
• Boiling Frog Syndrome — gradual negative changes are noticed only when it is already too late.
• Burning Bag of Dung — a manager leaves his neighbours (counterparts, subordinates, successor) in an awkward situation.
• Buzzword Mania — management juggles words that few of their subordinates understand.
• Deflated Balloon — the company's best years are behind it, but it cannot admit this and cut costs.
• Divergent Goals
• Dogmatic About Dysfunction
• Dunkirk Spirit
• Emperor’s New Clothes — after the fairy tale of the same name
• Fairness Doctrine
• Fools Rush In
• Founderitis
• Geek Hazing — newcomers are loaded with large amounts of trivial tasks that do not help them learn.
• Institutional Mistrust
• Kiosk City — every department develops its own mechanism for exchanging information.
• Mediocracy
• One-Eyed King
• Orange Stand Economics — poor cost estimation.
• Pitcairn Island
• Potemkin Villages
• Process Clash
• Rubik’s Cube
• Shoeless Children
• Worshipping the Golden Calf

Conclusions

Anti-patterns are recurring wrong decisions.

They occur not only in code, but also in:

• architecture,
• management,
• infrastructure,
• security,
• UX,
• SOA,
• AI systems,
• code reuse.

The main danger of anti-patterns is that at the beginning they often look like a perfectly normal solution:

But then they lead to technical debt, bugs, vulnerabilities, poor UX and the complication of the entire system.

See also

• [[b9239]]
• [[b7003]]
• [[b4563]]

See also

• SQL Antipatterns
• Spaghetti code