A design pattern is most assuredly not a best practice. In fact, it makes little sense to talk about a design pattern in isolation. It is a solution in a context. In some contexts it is appropriate and other contexts it is not appropriate. Design patterns used to have large preambles discussing the contexts where they were appropriate and where they were not.

The point about an anti-pattern is that it is surprising. It must be a common approach that looks like it should work, but it doesn't. It is definitely not a "bad practice", or an "I don't like that" practice, or even an "inappropriately applied pattern". It's a surprising result that you should be aware of that tends to catch people frequently.

Here is the first reference I know about discussing design patterns in software: https://c2.com/doc/oopsla87.html (Yes, the "87" refers to "1987"). People who have only read about design patterns in the last decade or two are almost certainly missing the original point (as seems to be sadly common with these kinds of things).

Take for example a load balancer that is configured to send traffic to the fastest server at the time. Makes sense, if a server is fast it has more available capacity to handle requests. But when the front end code fails the server short circuits, skipping all the expensive code as it unwinds the stack and returns a 5XX error, the load balancer that just sends to the fastest now sends ALL traffic to the failing node.

The antipattern is a feedback loop that is not measuring the right thing. In this case, they should be timing _successful_ calls to the front end.

Sure there might be a group of not too well-informed/skilled people religously believing patterns must be used whenever even remotely possible and not using patterns is bad, mkay, but I think (hope?) the group considering them as just another tool in the toolbox, used when appropriate but not otherwise, is larger.

Several. I've not worked in such an environment myself, but I've had colleagues who have; workplaces where every design is permitted only to use concepts from the big book of patterns and any situation to which they are inappropriate is nonetheless solved (badly) with that big book of patterns.

Can you name any of these workplaces?

I last worked with him when I was working for a UK offshoot of a US Defence company. This would have been somewhere around... six years ago, I guess.

I suppose I could try to dig out his contact details and ask him, but I won't. So the short answer is no, I can't name that company. Got a feeling it was something involving printing, or imaging.

I also cannot name any of the companies that any of my current colleagues have previously worked at. Is everyone else keeping track of where all their colleagues and ex-colleagues have worked? Wouldn't be surprised. I don't keep track of any of that. I'm not even on the facebook.

Shame, I was hoping to avoid them. I do know where quite a few people I have worked with have worked previously, purely because this kind of thing can come up in discussion and my memory sometimes functions.

>I'm not even on the facebook.

Congratulations. I've managed to never be on it either.

Is that not the very point being made?

Take all that, and then insist that all new code do that as well. That's what I'm talking about.

Anti-patterns can be patterns that have been proven through formal processes and the most successful of them tend to be.