"Preface In troubled organizations, a frequent obstacle to success is accurate problem identification. When problems are incorrectly diagnosed by management or by the consultants they hire, then correction of the problem is rarely possible. Conversely, when problems are correctly identified, they can almost always be dealt with appropriately. Unfortunately, organizational inertia frequently clouds the situation or makes it easier to do the wrong thing rather than the right thing. So how can one know whatthe right thing is if one has the problem wrong? This is where antipatterns can be helpful. Shortly after the emergence of patterns*, practitioners began discussing problem- solution pairs in which the conventional solution does more harm than good, known as "antipatterns." In their groundbreaking work, AntiPatterns, Brown, Malveaux, McCormick, and Mowbray (1998) described a taxonomy of problems that can occur in software engineering. They also described solutions or refactorings for these situations. The benefit of providing such a taxonomy is that it assists in the rapid and correct identification of problem situations, provides a playbook for addressing the problems, and provides some relief to the participants who can take consolation in the fact that they are not alone. Brown et al. organized their antipatterns into three general types: (1) architectural, (2) design, and (3) management. The architectural patterns describe bad practices that lead to unacceptable software architectures (for example, "Kitchen Sink"). The design antipatterns do the same for design (everyone knows about "Design by Committee"). The management antipatterns generally describe dysfunctional behavior of individual managers, or pervasive management practices that inhibit success"--