It is time to kick off a new season. Thus, we will set the tone by providing a general anti-pattern definition. Spoiler alert, this season will focus on anti-patterns much like we did software patterns of design a few seasons back. We will drift away from software design and implementation at times due to the more general applicability of anti-patterns.
Finding An Anti-Pattern Definition
There are a number of functional definitions out there. However, we will go to the source of truth on the Internet, Wikipedia. [Click Here to See The Page]
“An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. The term, coined in 1995 by Andrew Koenig, was inspired by a book, Design Patterns, which highlights a number of design patterns in software development that its authors considered to be highly reliable and effective.
The term was popularized three years later by the book AntiPatterns, which extended its use beyond the field of software design to refer informally to any commonly reinvented but bad solution to a problem. Examples include analysis paralysis, cargo cult programming, death march, groupthink and vendor lock-in.“
We can see from the above that the modern version of anti-patterns is still young. It spun off of the gang of four book that gave us patterns. However, anti-patterns have been with us since man made his first mistake. The simplest definition is that these tell us what to avoid.
Laugh or Cry
You might find bits of humor mixed in with the topics we cover. This is intentional. We will be looking at examples that fall under the category of those that you can either laugh or cry at them. You are more likely to laugh at those you have witnessed. On the other hand, you should grab a tissue for those you have lived through. Nevertheless, there are concrete examples for each of the warnings we address.
We found that software patterns often were supported in every modern language. These anti-patterns go beyond languages and even software in many cases. Thus, we will not even bother going down to a technical level except in those cases where specific examples help our understanding.