Antipatterns

If there are common patterns to be found in good software design, are there also patterns that can be found in bad software design? Absolutely! There is any number of ways to do things incorrectly but most of them have been done before. It takes real creativity to screw up in a hitherto unknown way.

The shame of it is that it is very difficult to remember all the ways in which people have gone wrong over the years. At the end of many major projects, the team will sit down and put together a document called lessons learned. This document contains a list of things that could have gone better on the project and may even outline some suggestions as to how these issues can be avoided in the future. That these documents are only constructed at the end of a project is unfortunate. By that time, many of the key players have moved on and those who are left must try to remember lessons from the early stages of the project, which could be years ago. It is far better to construct the document as the project progresses.

Once complete, the document is filed away ready for the next project to make use of it. At least that is the theory. For the most part, the document is filed away and never used again. It is difficult to create lessons that are globally applicable. The lessons learned tend to only be useful for the current project or an exactly identical project, which almost never happens.

However, by looking at a number of these documents from various projects, patterns start to emerge. It was by following such an approach that William Brown, Raphael Malveau, Skip McCormick, and Tom Mowbray, collectively known as the Upstart Gang of Four in reference to the original Gang of Four, wrote the initial book on antipatterns. This book, AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis, John Wiley & Sons, Inc., outlined antipatterns for not just issues in code but also in the management process that surrounds code.

Patterns outlined include such humorously named patterns as The Blob and Lava Flow. The Blob, also known as the god object, is a pattern in which one object grows to take on the responsibility for vast swaths of the application logic. Lava Flow is a pattern that emerges as a project ages and nobody knows if code is still used. Developers are nervous about deleting the code because it might be used somewhere or may become useful again. There are many other patterns described in the book that are worth exploring. Just as with patterns, antipatterns are emergent from writing code, but in this case code that gets out of hand.

This book will not cover JavaScript antipatterns, but it is useful to remember that one of the antipatterns is an overapplication of design patterns.