design, architectural, and management.2 More recently, Phil

trade-offs, and design rationale and make these lessons learned widely available for off-the-shelf use. They can also enhance developers ’ vocabulary—for example, by easing the transition to object-oriented programming.2 Conventionally, patterns consist of four elements: a name, the problem to be solved, the solution to the problem (often termed the refactored solution), and the consequences of the solution. Numerous sets of patterns (collectively known as pattern languages) exist for software design, analysis, man-agement, and so on; a Web search on “pattern language” yields many hits. Shortly after the notion of design patterns emerged, practitioners began discussing problem-solution pairs in which the solution did more harm than good.3,4 These have come to be known as antipatterns, and they are well known in the design and management communities. Antipattern examples In 1998, researchers discussed three kinds of antipatterns