One common antipattern in software engineering is the Antipattern Antipattern:
Thinking that the term "antipattern" means "never use this pattern."
"An antipattern is just like a pattern, except that instead of a solution it gives something that looks superficially like a solution, but isn't one."
Andrew Koenig, Journal of Object-Oriented Programming, April 1995
Antipatterns are disguised as good solutions. The danger is when the pattern is applied without evaluating the alternatives. Antipatterns become antipatterns when:
The patterns results in unintended and undesired outcomes and another pattern exists that is a repeatable and effective solution.
That means that antipatterns are context-dependent. Antipatterns can be the best solution when other patterns do not exist or are not effective solutions. The context of the problem you want to solve and the system you are working in can change an antipattern into a pattern.
So, what's the fix to the Antipattern Antipattern?
Understanding that more often than not the antipattern will not be the solution you want. But if the evaluated alternatives are not effective, the antipattern can be used with the knowledge of the potential desired and undesired outcomes.
Oldest comments (5)
Do you have an example for an antipattern that you used when you found no other effective solution?
Would have been better if you provided a concrete example / situation with this one to strengthen and support your points.
Looking at the list of anti-patterns on Wikipedia, the best candidate for being an antipattern antipattern would be copy-paste programming. There is value in copy-paste programming, depending on context. One case would be in an early version of your software, where you would first copy-paste some things to get your code running and then try to abstract where beneficial.
Another case is something that was mentioned in a lecture I attended 6 or 7 years ago, so I don't remember the details. There is a lot of code duplication in some of the Linux drivers, and I think it was the graphics drivers. IIRC, the drivers are responsible for a lot of configuration, which is of course very similar between similar graphics cards. Of course there is a lot of code shared and abstracted away, but there was still a lot of copy-pasting of code. And, for this particular use case, it was the best implementation (or at least a local optimum).
I love this game.
React is an example of a technology which was a HUGE antipattern for web developers and eventually it became what everyone was doing... until the next antipattern buster.
Not that one is wrong for thinking of something as an antipattern, but it’s often used to end conversations instead of starting them. Clean code follows many patterns, and if things are done with care I don’t think anything is an antipattern in and of itself.
The antipattern should mean using pattern the way it was not intended to therefor making an extra complexity problem instead of having a common solution to a common problem. Anything more than that will lead to philosophy as in functional programming and object oriented programming where, after given amount of time developers would discuss it as possible good practice.