Anti-pattern (from the English anti-pattern; also known as a trap, English pitfall) — this is how you should not act, but how absolutely everyone, always and everywhere, acts anyway. No matter how much they're warned. Because deadlines. Because business. Because idiots.

The term came from computer science, from the «Gang of Four» book Design Patterns, which laid down examples of good programming practice. The authors called these good methods «design patterns», and their opposites, accordingly, are «anti-patterns». In principle, anti-patterns apply not only in IT, but in any other field of human activity.

Programming anti-patterns

• Hard code, from the English hard code — also called being «nailed down». Code that is so tied to a specific hardware configuration and/or system environment that tearing it out for use elsewhere can only be done with a crowbar.
• Soft code, from the English soft code — almost the same as a soft stool, or, in technical terms, code configured so flexibly (and confusingly) that you'd wish it were hard code instead. It arises from moving program logic out into configuration files, which, in reasonable amounts, is sometimes actually justified.
• Magic numbers, from the English magic numbers — what hard code is often built on. All sorts of constants in a program with no explanation of their physical (or any other) meaning. As a rule, when a magic number is changed or removed, the code magically stops working altogether. Typical examples — 17 and 54.
• Magic strings, from the English magic strings — like magic numbers, but these are strings.
• Magic button, from the English magic button — all the code is written inside the button click handler. This afflicts every language with a GUI editor — C#, Delphi.
• Races, English race condition, race hazard — these begin when a programmer enters the wondrous world of parallel programming with its threads, streams and semaphores.
• Accidental complexity, from the English accidental complexity — making something complicated when it could be done simply. As a rule, a programmer wants to apply everything they've just learned as fast as possible (and that new library over there for exchanging data over the XXX protocol), and also wants to walk away from the project with a bunch of new lines for their resume. If this desire wins out over reason, the project ends up with accidental complexity. See also the articles Indian Code and KISS.
• Spaghetti (a.k.a. a hodgepodge) of code, from the English code spaghetti — this is exactly the kind of code you're once handed to maintain, and after five minutes of combing through your hair standing on end while reading it, you silently close the editor and open a browser to some job board looking for a vacancy at a more decent company, one that doesn't practice such cruelty toward its programmers. It's characterized by a single piece of code describing a pile of entities mixed together beyond all understanding, which really ought to be kept separate. For example, HTML tags inside PHP code instead of moving all the markup into templates.
• Katamari — adding new features exclusively as external crutches and props instead of periodically revisiting the base functionality. As a result, over time the code turns into a tight lump of some kind of substance that even the developers themselves refuse to poke around in. As a result, you get the next round of crutches and props. This can happen in a single isolated piece of code, or globally across the entire project.
• God Object, from the English God Object — a small piece of code where everything is concentrated. Literally everything. There's possibly even a decently sized galaxy hiding in there. All the rest of the program's code is purely decoration around the God Object.
• Detonator, from the English detonator — very common, but rarely spotted. A clear example: using a two-digit field in date calculations. The bomb is planted, and the detonator will go off sooner or later
• Not-My-Fault, English absolver — this pattern is found in code written by former company employees. So many old problems are locked up in such code that current employees can defend their own work from criticism by claiming that someone else's code is the cause of all the bugs that show up. Also known as That's-Not-My-Edit.
• Historical Contribution, from the English stake — this pattern occurs in a program written by an employee who was later promoted. Despite the abundance of bugs in the program, this employee's contribution is too great to let anyone start rewriting the code, since it is the pinnacle of this comrade's technical achievements.
• Public Morozov (a purely Russian idiom, with no English equivalent) — a class that, on request, hands out access to all of the parent class's properties, even the private ones. Not so much bad in itself as a sign that something in the code is off.
• Saving Private Ryan, from the English Private Ryan — a pattern in which access to a field is technically possible, but only by mounting an expedition fraught with all kinds of danger.

System administration anti-patterns

Sysadmins get two anti-patterns of their own, depending on their specialization.

• Dependency hell, from the English dependency hell — for Unix sysadmins. It follows straight from the fact that the builders of Unix distributions (Linux ones especially) once grew proud and decided to build a Tower of Babel to bring order to all Linux software, so that no one program in the distribution would get in another's way. Users sometimes feel the consequences of this attempt in the form of «circular dependencies» and other paths into dependency hell.
• DLL hell, from the English DLL hell — a personal favorite for Windows sysadmins. This problem is a special case of dependency hell, applied to the library format (DLL) in Windows, especially in older versions of that system.

Organizational anti-patterns

There is an art called «herding cats», or, to put it boringly, managing programmers. Drawing all sorts of Gantt charts and other pseudo-scientific nonsense that everyone then cheerfully ignores. This is what managers do. It's no secret that people go into management when they've reached the end of their road in IT, grown old and dull for writing code and crafting things built to last, or maybe never used anything besides Word and Outlook to begin with and so went straight into being building superintendents managing people. That's why anti-patterns flourish so lushly in this area. Sometimes the developers themselves add extra disorganization to the development process, helping managers introduce anti-patterns of their own.

• Mushroom management, from the English mushroom management — a method of managing subordinates on the principle: you are all ants, and I am the anthill! The English slogan of the mushroom manager is «we keep them in the dark and feed them a steady diet of manure» (Richard Henderson). The manager tends the mushrooms in every way possible, convincing subordinates that besides their immediate assignments they need to know nothing else, and that racking their brains over the project as a whole is strictly a manager's business. To apply this method, the project is broken into pieces of a puzzle that can't be reassembled, so that no one understands what they can be put together into at all, and each person is then handed out enough of these pieces to keep the mushrooms permanently busy with work and not distracted by thoughts like «why on earth are we even doing it this way?». As a rule, mushroom management leads to total failure in the end, since the manager himself forgets (or never understood in the first place) where the project is headed and why. What's curious is that mushroom management is practiced not only by managers, but also by individual programmers who find themselves in senior roles on a project. As a rule, this is a sign of unqualified programmers, afraid to reveal to their colleagues the little knowledge they actually have — lest it be discovered how small it is. The same reason applies to managers as well.
• Seagull management, from the English seagull management or corporate seagull — a common subclass of managers who operate in the following sequence: fly in, squawk, and fly off, leaving behind little piles of project excrement that subordinates then have to clean up while cursing. Their behavior resembles that of seagulls, soaring proudly between the clouds and the sea and swooping down to the shore to quickly grab a bite and empty their bowels in passing, which is where they (the managers) picked up this name. The most useless type for project work, but management loves them, since corporate seagulls are great at flapping their wings loudly to draw attention to themselves, passing off penny-ante activity as great achievements. They're hard to kill and hard to catch making mistakes, since they never make any (because, as is well known, that would require actually doing something).
• Design by committee, from the English design by commitee — the IT equivalent of the saying «too many cooks spoil the broth». It balloons into gigantic, unviable standards and specifications with over 9000 levels of abstraction, which in the end nobody implements anyway. Examples — the OSI model[WHAT?] and CORBA.
• Analysis paralysis, from the English analysis paralysis — the project gets stuck at the task-analysis stage, in endless arguments about «the best way to do it». The result is that it doesn't get done at all.
• Knight in Shining Armor (KISA), from the English Knight in shining armor (KISA) — an infallible personality, with a self-worth at least equal to the square of his own technical qualifications. Appears on the scene at a moment of crisis and starts fixing everything in sight, and, as a rule, fixes it successfully — just without any notice of what changes he made, or why. So at the next system update, the unsuspecting sysadmin finds the old bugs creeping right back into place, which gives the Knight in Shining Armor cause to declare everyone around him stupid and incompetent, which further inflates his aura of infallibility.
• All Hands on Deck!, from the English Tempest Method — applied no earlier than a few days before the project is due. At this point programmers start urgently generating code with no comments, riddled with bundles of bombs fitted with detonators.
• Witch hunt, from the English witch hunt — attempts to find a scapegoat after successfully deploying the anti-patterns above, but since that doesn't solve any problems, the result is the hunting down of ever more scapegoats. In the final round of the game only one must remain — Duncan McLeod, the manager on a white horse, armed with confirmations of the previous team's incompetence and assurances to the firm's leadership that the new team under his guidance will achieve unprecedented project success.

Anti-cleverness

As the humble programmer E. Dijkstra put it: «The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task with full humility».

Misconceptions about the brain power of a manager or a programmer are a permanent source of anti-patterns.

• Exploiting the technology's potential at 110%. The rapid growth of platforms, development tools, and their ever-expanding feature sets clouds the mind of the average coder, who assumes that unless he writes code with ten operators per line, uses every possible variant of generators, templates, tags, subtle interpreter quirks and low-level system hacks, his colleagues will consider him a total junior. But, as a rule, things turn out exactly the opposite, and every clever trick in the code comes back to bite you many times over during the product's later maintenance, not to mention that the poor developers of platforms, environments and libraries pack in a pile of features purely for show, giving them exactly as much attention as that deserves. Meanwhile, simple and clear old-school approaches, which don't necessarily mean a rigid cookie-cutter method, are usually more than enough to solve the vast majority of tasks.

• Manipulating deadlines. Sooner or later, every effective manager gets the idea that maybe developers should be told a deadline 3.14 times shorter than the estimate, to make them hustle, though if investment money has clouded his mind, then 3.14 times longer instead, so that this time they'll definitely make the deadline. The thought that things will go relatively well only if the work plan actually matches the estimate of the work volume is considered far too banal and unworthy of a true management guru. As a consequence — a great many projects end spectacularly.

• Cost-cutting. Since the client often wants a golden castle for the price of a bucket of rotten manure, the question of cost-cutting comes up. True cleverness dictates that instead of cutting the layer of gilding in half (trimming features and requirements), it's better to cut down on design, prototyping, internal conventions, tests, automated tests, the development team, and other things that were never going to be done properly anyway. Naturally, the answer to the key question is obvious, since a plant that produces denatured alcohol will never manage to turn out a barrel of Scotch whisky — something everyone more or less understands in their head, but still wants in their heart all the same.

• Exploiting staff potential at 110%. It never occurs to the average effective project manager that a programmer who writes ten lines a day can rightly be called someone who's worked normally, while a hundred solid, debugged and tested lines means he's worked outstandingly. This leads him to the idea that a secretary could be put in as a programmer instead, since her typing speed is higher, but since the secretary refuses, managerial logic suggests it's time to whip up a panic, run around like a headless chicken, and stimulate the process by every means possible in order to squeeze out a 110% return. As a result, the project dies under its own technical debt (bad decisions, wrong estimates, and just plain bugs) without ever really getting off the ground. As a rule, though, the manager himself is usually the first to keel over, while the development team, having polished up their resumes, crawls off to some other outfit the very next day, hoping for something better.

Resign Patterns

Breaches of Project-Disoriented Design

Anyone familiar with the book on patterns written by that very Gang of Four knows that the patterns listed there are elegant solutions worked out over years. Unfortunately, it's not possible to extract patterns from existing code, because the authors of that code didn't know they were supposed to use patterns. This work is a collection of patterns for the people. The patterns listed here are solutions that have stood the test of time. I wish you pleasant reading, but please, don't you dare actually use them!

1. Killer Patterns

Below is a list of five killer patterns.

1.1. Abject Poverty

The Abject Poverty pattern is widely found in programs that are so difficult to test and maintain that it results in constant budget overruns.

1.2. Blinder

This pattern is a solution well-suited to the problem, without any regard for possible changes to the original requirements. It remains unclear to this day whether this pattern is named that way because the engineer puts on blinders during the coding phase, or because you can go blind while operating such software.

1.3. Fallacy Method

The Fallacy Method pattern describes how exceptional situations are handled. The logic looks sound, but if anyone bothers to test the application, or an exceptional situation actually occurs, the fallacy of that logic comes crawling right out.

1.4. ProtoTry

The ProtoTry pattern is an attempt to hastily throw together a working model of the application. The natural desire is to rewrite ProtoTry, taking into account the lessons learned from it, but deadlines are looming. ProtoTry is also known as existing code (legacy code).

1.5. Simpleton

Simpleton is a horrifically over-engineered pattern used to solve the simplest possible tasks. It is a precise indicator of the professional level of whoever uses it.

2. Structureless Patterns

Below is a list of seven structureless patterns.

2.1. Adopter

The Adopter gives shelter to homeless functions. The result is a family of functions that look nothing like one another and are connected to each other only through the Adopter.

2.2. Brig

The Brig is a container class for crooked software. Also known by the name module.

2.3. Compromise

The Compromise pattern is used to strike a balance between development deadlines and product quality. The result is a mediocre application — and it's still late.

2.4. Detonator

The Detonator is very common, but often goes unnoticed. A simple example — calculations based on the last two digits of the year. The Detonator is somewhere nearby, just waiting to go off!

2.5. Fromage

The Fromage pattern is full of holes. This pattern consists of small, shabby tricks that ultimately kill the application's portability. The older the Fromage, the better it «smells».

2.6. Flypaper

The Flypaper pattern is written by one engineer and maintained by another. The engineer maintaining the Flypaper soon discovers he's stuck fast, and he's more likely to die than get free.

2.7. ePoxy

ePoxy is found in tightly coupled modules. The stronger the coupling between them, the more noticeable the layer of ePoxy between them becomes.

3. Patterns of bad behavior

Below is a list of eleven patterns of bad behavior.

3.1. Chain of Possibilities

Chain of Possibilities is found in large, poorly documented modules. Nobody knows the full functionality of such a module at all, yet its possibilities seem endless. Also known as Non-Deterministic.

3.2. Commando

Commando is used to burst into the work quickly and get it done just as quickly. Commando may break encapsulation to successfully accomplish its mission. Motto — take no prisoners.

3.3. Intersperser

The Intersperser scatters bits of functionality throughout the entire system, hindering the testing, maintenance, or understanding of any of its functions.

3.4. Instigator

The Instigator looks sweet and harmless at first glance, but in reality sows destruction and chaos in other parts of the system.

3.5. Momentum

Momentum grows exponentially, increasing memory and disk space requirements, as well as the application's complexity and running time.

3.6. Medicator

The Medicator is a genuine time-eater, while the rest of the system literally has to be revived and given sedatives.

3.7. Not-My-Fault (Absolver)

The Not-My-Fault pattern is found in code written by former company employees. So many old problems are locked up in such code that current employees can defend their own work from blame by claiming that someone else's code is the cause of all the bugs that show up. Also known by the name That's-Not-My-Edit.

3.8. Contribution (Stake)

The Contribution pattern occurs in applications created by engineers who were later promoted. Despite the abundance of bugs in the program, this engineer's contribution is too great to let anyone start rewriting this code, since it is the pinnacle of this comrade's technical achievements.

3.9. Eulogy

The Eulogy pattern is applied in all projects that already use the other 22 patterns. Also known as the Funeral Oration.

3.10. All Hands on Deck (Tempest Method)

The All Hands on Deck method is applied in the last few days before the project is due. This pattern is characterized by a lack of comments and repeated use of the Detonator pattern.

3.11. Visitor From Hell

The Visitor From Hell pattern is akin to the absence of an array-bounds check at runtime. At least one control loop for the system will inevitably summon the Visitor From Hell, who is sure to overwrite vital data.

See also

• SOLID
• GRASP
• Principles and purpose of OOP/OOD/OOA
• [[b7888]]
• [[b9239]]
• [[b7003]]

• [[b4842]]

See also

• Quality code in the design.SOLID , Principles and purpose of OOP / OOD / OOA Code
• SQL Antipatterns
• Anti-pattern (trap): how NOT to do it
• Design Pattern