Learning from Antipatterns

As a full time University student, one of my lecturers once told the class to do ourselves, our future employers and co-workers a favour, and get ourselves an education. The context of this statement was a discussion about professional programmers who through lack of knowledge wrote code that naively approached problems that were in fact NP-Hard. At the time I thought nothing further of it, but as I started working I quickly realised the value of the statement.

Patterns are one popular way of transferring knowledge, experience and learning. First formally described by Architect Christopher Alexander in the form of a Pattern Language, Patterns have informally been around for as long as intelligent human beings (the best shape for a door is generally a rectangle and the best shape for a wheel is generally a circle). Many fields of knowledge have their own patterns, for example: Software Engineering, Interaction Design and Scrum.

Learning from Patterns is pretty straight forward: Somebody else solved a problem in a particular way and described it; enough people found it to be a valid solution to their own similar problem to consider it a generic solution; if you have a similar problem, try the same solution. Straight forward right? I might rant further about Patterns someday, but what interests me today are Antipatterns.

A skunk! by tambako (CC BY-ND 2.0).

Antipatterns are similarly simple: Somebody else tried to solve a problem in a particular way and failed; others who tried to take the same approach failed too; the approach seems to lead to failure so let’s stay away from it.

An Antipattern is a documented recipe for failure.

Of course I am all for challenging the status quo, thinking outside the box or whatever other fancy way you have of describing original thought. However the keyword is think not box. Think about a problem before jumping at a solution, learn from the success of others described in Patterns, define your own new Patterns best suited to your organisation, and if all the information you have points to a solution that is a documented Antipattern, sure try it out, but be prepared and keep a fire extinguisher close by.

If you are not the person taking the decisions, but you observe one frustrating Antipattern after another, hang in there. Observe and learn from their mistakes, both the Antipatterns and the innovative failures. Learning from failure is one of the best ways to learn and if the cost of the mistake is not yours to bear, it is a real bonus. Speak up about things, your reasoning should never be “because a book said so” but instead you should understand the principles behind the Pattern or Antipattern and apply them as closely as possible to your specific scenario. If possible, apply Patterns to your own area of responsibility and point to them as contributors to your success.

So, when I point out that your approach is a known Antipattern and explain why it will unlikely result in success, don’t tell me that this is the real world and that is the way things get done here, shut up and read a book. Come back when you have something to discuss.