Welcome to the Antipatterns subsite of Dr. Phil Laplante and Dr. Colin Neill of the Software Engineering Research Group at Penn State University's Great Valley School of Graduate Professional Studies

Please use the tabs above to navigate.

To software engineers a pattern is a named problem-solution pair that is used to enable large-scale reuse of software designs and architectures.

Shortly after the emergence of patterns for design, analysis, management, and so forth practitioners began discussing problem-solution pairs in which the conventional solution does more harm than good, known as "antipatterns". There are numerous sets of patterns (collectively known as "pattern languages") for software design, analysis, management, and so on.

We have identified a number of environmental antipatterns, and we keep adding to this list. Traditionally, a pattern is described by its name, a description, the solution or refactoring to the problem and the possible consequences of the solution.

Our antipatterns have an informal structure that concentrates on identification of the dysfunctional situation, and remedies for all those involved. Our antipatterns take the following form:

• Name: A Name that conveys the antipattern's meaning.
• Central Concept: A short synopsis of the antipattern. Enough to make the antipattern identifiable.
• Dysfunction: In general terms, the problems with the current practice, possibly with a list of symptoms.
• Vignette: The antipattern in a real or prototypical situation. This section provides context and richness to the antipattern.
• Explanation: Expanded explanation of the antipattern including its causes, consequences and historical or cultural analogies.
• Band Aid: A short-term fix or coping strategy for those in the midst of the antipattern who have neither the time or influence to refactor it properly.
• Self-Repair: The first step for someone perpetuating the antipattern. How you can help yourself improve.
• Refactoring: Description of the changes that should be made to remedy the situation and their rationale. Sometimes these are under the control of an individual, but often they involve cultural or institutional changes.
• Observations: Optional section for additional comments or items of note.
• Indentification: An assessment instrument consisting of a list of questions for diagnosis of the antipattern. It must be stressed that this instrument is for informal evaluation – no validity or reliability testing has been performed. Hopefully they will resonate with those suffering from the antipattern, and possibly provide humor!

Here is a list of our Antipatterns organized into two groups: management and environmental. To learn more about these antipatterns, please take the Antipatterns test (and read our book).

For more information on the authors, you can visit their personal websites here:

• Phil Laplante, Robert Hoffman, and Gary Klein, "Antipatterns in the Creation of Intelligent Systems," Intelligent Systems, January/February, 2007, pp. 91-95.
• Phillip A. Laplante, "Mal Managerium: A field guide to watching and handling bad tech managers," Queue, vol. 3, no. 4, May 2005, pp. 62-64.
• Phillip A. Laplante, "The Potemkin Village and Other Myths of Deception," IT Professional, February 2005, pp. 63-64.
• Phillip Laplante, "The Burning Bag of Dung : And Other Environmental Antipatterns," Queue, October 2004, pp. 78-80.
• Phillip A. Laplante, "Staying Clear of Boiling Frog Syndrome," IT Professional, March/April, 2004, pp. 56-58.
• Phil Laplante, "Situational Antipatterns: How not to run a restaurant," Harris Kern's Enterprise Computing Institute, available at www.harriskern.com, December 2003.

If you are interested in buying our book (now in its second edition), check out the links below.

• Amazon
• Barnes & Noble