Disloyal
There’s another kind of pattern. It’s the type of pattern everyone recognises and puts on the naughty list. These are the anti-patterns. The only difference between them and other patterns is that they hurt rather than help you. Anti-patterns are natural patterns that cause you problems. It’s helpful to recognise them quickly and find details on an alternative, a replacement pattern you want to use, or at least a method by which to extract yourself from the anti-pattern. If regular design patterns are wisdom, and wisdom is what you should avoid doing, anti-patterns are the design patterns of what makes sense at the time but you really shouldn’t do.
There are other sub-categories on the negative continuum. From patterns that are good but have some warnings to those that aren’t self-forming, but we genuinely want them to be. This is why I use the term disloyal. Patterns don’t care about humans, buildings, code, or customers. They just exist. Sometimes, they hurt by design; sometimes, they are extremely rewarding in a bad way, like chocolate cake.
The pattern of building large sweeping corners to reduce the chance of clipping the curb causes fewer bent wheel rims. But it increases pedestrian fatalities because visibility drops, time to cross lengthens, and cornering speeds increase. The pattern was self-reinforcing and self-forming, but ultimately, it’s an anti-pattern.
The pattern of building more auto-complete technology into IDEs is an obvious benefit to people wanting to code faster without looking up the API. But it comes at the cost of a shallow understanding of APIs and the increasing length of names without an equal increase in clarity of meaning.
The point is that patterns exist whether you benefit from them or not. Making anti-patterns visible is the first step to undoing any damage they cause.