WebSeitz/wiki

Anti-Pattern

a Pattern with negative consequences

Worst Practices

WikiWikiWeb:AntiPatterns

WikiWikiWeb:AntiPatternsCatalog

A format that makes sense to me:

  • start with the straight pattern template
  • turn "Resulting Context" into list of outcomes, which will be mostly negative side-effects
  • add "Refactored Solution", with its "Refactored Resulting Context"

multiple books use the title/framing

  • 1998: AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by William Brown, Raphael Malveau, Skip McCormick, Tom Mowbray https://en.wikipedia.org/wiki/AntiPatterns The essence of an AntiPattern is two solutions, instead of a problem and a solution for ordinary design patterns. The first solution is problematic. It is a commonly occurring solution that generates overwhelmingly negative consequences. The second solution is called the refactored solution. The refactored solution is a commonly occurring method in which the AntiPattern can be resolved and reengineered into a more beneficial form. Ralph Johnson, one of the primary proponents of patterns, has led much of the work in this area. 3 sections: software development; software architecture; project management.... that last bucket includes:
    • Blowhard Jamboree: The opinions of so−called industry experts often influence technology decisions. Controversial reports that criticize particular technologies frequently appear in popular media and private publications. In addition to technical responsibilities, developers spend too much time answering the concerns of managers and decision makers arising from these reports.
    • Analysis Paralysis: Striving for perfection and completeness in the analysis phase often leads to project gridlock and excessive thrashing of requirements/models. The refactored solution includes a description of incremental, iterative development processes that defer detailed analysis until the knowledge is needed.
    • Viewgraph Engineering: On some projects, developers become stuck preparing viewgraphs and documents instead of developing software. Management never obtains the proper development tools, and engineers have no alternative but to use office automation software to produce psuedo−technical diagrams and papers.
    • Death by Planning: Excessive planning for software projects leads to complex schedules that cause downstream problems. We explain how to plan a reasonable software development process that includes incorporating known facts and incremental replanning.
    • Fear of Success: An interesting phenomenon often occurs when people and projects are on the brink of success. Some people begin to worry obsessively about the kinds of things that can go wrong. Insecurities about professional competence come to the surface.
    • Corncob: Difficult people frequently obstruct and divert the software development process. Corncobs can be dealt with by addressing their agendas through various tactical, operational, and strategic organizational actions.
    • Intellectual Violence: Intellectual violence occurs when someone who understands a theory, technology, or buzzword uses this knowledge to intimidate others in a meeting situation.
    • Irrational Management: Habitual indecisiveness and other bad management habits lead to de facto decisions and chronic development crises. We explain how to utilize rational management decision−making techniques to improve project resolution and for keeping managers on track.
    • Smoke and Mirrors: Demonstration systems are important sales tools, as they are often interpreted by end users as representational of production−quality capabilities. A management team, eager for new business, sometimes (inadvertently) encourages these misperceptions and makes commitments beyond the capabilities of the organization to deliver operational technology.
    • Project Mismanagement: Inattention to the management of software development processes can cause directionlessness and other symptoms. Proper monitoring and control of software projects is necessary to successful development activities. Running a product development is as complex an activity as creating the project plan, and developing software is as complex as building skyscrapers, involving as many steps and processes, including checks and balances. Often, key activities are overlooked or minimized.
    • Throw It over the Wall: Object−oriented methods, design patterns, and implementation plans intended as flexible guidelines are too often taken literally by the downstream managers and object−oriented developers. As guidelines progress through approval and publication processes, they often are attributed with unfulfilled qualities of completeness, prescriptiveness, and mandated implementation.
    • Fire Drill: Airline pilots describe flying as “hours of boredom followed by 15 seconds of sheer terror.” Many software projects resemble this situation: “Months of boredom followed by demands for immediate delivery.” The months of boredom may include protracted requirements analysis, replanning, waiting for funding, waiting for approval, or any number of technopolitical reasons.
    • The Feud: Personality conflicts between managers can dramatically affect the work environment. The employees reporting to these managers often suffer the consequences of their supervisors’ disagreements. Animosity between managers is reflected in the attitudes and actions of their employees.
    • E−mail Is Dangerous: E−mail is an important communication medium for software managers. Unfortunately, it is an inappropriate medium for many topics and sensitive communications.
  • 2006: AntiPatterns: Identification, Refactoring, and Management by Phillip A. Laplante, Colin J. Neill
  • 2012: Antipatterns: Managing Software Organizations and People by Colin J. Neill, Phillip A. Laplante, Joanna F. DeFranco. Appears to be a new edition of the previous book. Scales from individual human personality issues, to Groups, to Manager practices, to Environmental issues (culture, etc). But even at the top level they feel micro-execution oriented to me.
  • 2022: Software Development Patterns and Antipatterns by Capers Jones. Topics/frame: project management, estimating, defects. (Very classic software engineering gloss.)

Martin Cagan wrote 2 of my favorite critiques of what I'd call anti-patterns (cf Dark Agile)

Edited:    |       |    Search Twitter for discussion

Made with flux.garden