veryard projects - innovation for demanding change

design pitfalls as negative patterns

on this page
  • What is a negative pattern?
  • Benefits
  • Use of negative patterns
  • Discovering new negative patterns
  • Describing negative patterns
  • Is a negative pattern always negative?
  • What is the goal?




  • Towns, Building & Construction

  • (Christopher Alexander)
  • Traditional Programming
  • Structured Modelling
  • Distributed Systems Engineering
  • OO & Component-Based Development
  • Organization Design
  • on other pages
    veryard projects
    home page

    negative patterns: more examples

  • Technology Transfer
  • Knowledge Management
  • Poor Scholarship



    pattern catalogue

    how to use patterns in your organization

    software quality management
    & process improvement

    contact us

    refactoring (bad smells)

    November 7th, 2000

    I've just reviewed Martin Fowler's book.  Chapter Three, written jointly with Kent Beck, describes twenty-two negative patterns - which they call Bad Smells.

    negative patterns

    False beliefs and strategies are always more interesting to me than true ones. For every orthodoxy there are dozens, perhaps hundreds of heresies.

    I've always thought that the most interesting task for a school maths teacher is working out how a particular pupil gets it wrong. Most cognitive errors are systematic rather than random - so if Johnny cannot do long division, there must be a specific step in the process that he is getting wrong, or a specific axiom or principle that he hasn't properly understood. This would be subject to mathematical analysis - if only school teachers had enough time and energy to do this. Alas, this doesn't seem to be part of their training.

    As a consultant specializing in processes and methods, I cannot sell common sense. (I wouldn't know how to install it, and anyway the people who need it most won't buy it.) But if I can identify a common pitfall or elephant trap, then I can get some business as a guide, steering people around or away from the pitfall. I may also get some salvage business. One of my missions as a consultant is to improve processes by identifying, eliminating or mitigating practical misconceptions, misalignments and mispractices.

    This page explores some noted pitfalls, mostly in the field of systems engineering. I shall identify some commonly occurring negative patterns (with hotlinks to pattern descriptions wherever possible), and will discuss general ways (also patterns) in which negative patterns in a given design may be identified and treated. It includes a tentative repository of negative patterns and guidelines for their use. Additional ideas and contributions are welcome.

    What is a negative pattern?

    Many patterns can be expressed in negative form: avoid XYZ. Experienced engineers have a personal set of negative patterns (or design pitfalls) that they search for when evaluating or testing other people's designs. Some of these negative patterns have a corresponding positive pattern: "avoid XYZ, do PQR instead".

    Note: some people refer to these as antipatterns.

    What are the benefits of identifying and using negative patterns?

    There are several possible benefits. Some of these benefits are available to an individual software developers, wanting to improve their personal design expertise and effectiveness. Some of the benefits require some level of coordination, either informal or formal, between individuals and teams within a larger software organization.

    How do we use negative patterns?

    There are several ways we can achieve these benefits.
    designerdesign inspectionsinspector

    How do we discover new negative patterns?

    Here are some ways of prompting the identification. Most people find it much easier to identify negative patterns than positive patterns, at least to start with.
    Design Patterns What is the commonest design pitfall you encounter? What is is the cause of this occurring?
    Process Patterns Where is the greatest risk for the project manager? If you were the project manager, what would keep you awake at night?
    Organization Patterns Imagine you are offered a job or contract by a new company. What do you ask at interview to find out whether this is an okay company to work for? What organizational patterns would put you off accepting?

    Then we may need to generalize the patterns, to make them more useful.

    How do we analyse and describe negative patterns?

    We usually start with a common source of error or defect, with a significant negative impact (therefore high risk). This is a template for recording negative patterns. It is based on the Gang of Four's template. 
    Pattern Name (Scope, Purpose) The pattern's name conveys the essence of the pattern succinctly. A good name is vital, because it will become part of your design vocabulary.
    Risk A short statement that answers the following questions: What does the design pattern do wrong? What is the rationale and intent for eliminating or avoiding it? What particular design issue or problem does it fail to address?
    Also Known As Other well-known names for the pattern, if any.
    Motivation A scenario that illustrates the potential consequences of using this pattern. The scenario will help you understand the more abstract description of the pattern that follows.

    Known Uses

    What are the situations in which the design pattern can be found? How can you recognize these situations? 

    An applicable situation.

    Examples of the pattern found in real systems. We include at least two examples from different domains. 

    Structure If possible, a pattern should be articulated - in the same sense that an articulated lorry is articulated.
    Healing Patterns References to patterns that may be used instead of the defective pattern, or which may be used to amelioriate its negative effects. 

    In some cases, the replacement or addition of these healing patterns can be semi-automated, in the form of a design Wizard.

    Related Patterns What design patterns are closely related to this one? What are the important differences? With which other patterns should this one be used?

    Is a negative pattern always negative?

    No.We need to understand the context for a pattern. A pattern may be positive/appropriate/useful in one context, and negative/inappropriate in another. Or in combination with other patterns.

    Disease mutates and evolves: new flu viruses, more virulent forms of TB. As the human immune system and/or the drug companies develop resistance to one form, another form appears, which elegantly evades our best defences.

    Once upon a time, computer programmers could easily recognize spaghetti code by the presence of one word: GOTO. It was considered harmful; programming languages were developed in which GOTO was unnecessary or impossible; generations of programmers were trained to resist anything that resembled a GOTO. But the pattern or meme mutates, and reappears in a new form, designed to bypass our programmed resistances. Large complex computer systems are now being developed; each software component may be impeccably designed and coded, but these software components are wired together (using some form of scripting language) into something that we can only regard as a new manifestation of spaghetti.

    Meanwhile, programmers who understood the dangers of spaghetti, and had valid reasons for using GOTO, were often bullied by quality inspectors with a fixed idea: GOTO considered harmful.

    The use of good patterns, and the avoidance of negative patterns or anti-patterns, can easily become trite or obsessional. An interesting pattern mutates, evolves, morphs. We must be alert to every new manifestation.

    What is the goal?

    Definitions donít matter 
    • What is a pattern?
    • What is an anti-pattern?
    • What is a negative pattern?
    Templates and classifications are useful but arbitrary
    The goal is the process. 

    What matters is the way we work with patterns

    • How we speak with patterns
    • How patterns speak with us
    • How patterns help people, teams and organizations to learn more effectively

    Ultimately, it isnít THE PATTERN that matters.

    What matters is PATTERNING



    Bedrooms make no sense.  Bed Alcoves

    Dressing Rooms

    A building in which the ceiling heights are all the same is virtually incapable of making people comfortable. Ceiling Height Variety
    High buildings make people crazy. Four Storey Limit
    Outdoor spaces which are merely 'left over' between buildings will, in general, not be used.  Positive Outdoor Space
    Continuous sprawling urbanization destroys life and makes cities unbearable. 

    The surburb is an obsolete and contradictory form of human settlement.

    The homogeneous and undifferentiated character of modern cities kills all variety of life styles and arrests the growth of individual character.

    The artificial separation of houses and work creates intolerable rifts in people's inner lives. 

    City Country Fingers 

    Lace of Country Streets

    Mosaic of Subcultures

    Scattered Work

    If a population of a region is weighted too far toward small villages, modern civilization can never emerge ... ... but if the population is weighted too far toward big cities, the earth will go to ruin because the population isn't where it needs to be, to take care of it. Distribution of Towns
    Cars give people wonderful freedom and increase their opportunities. But they also destroy the environment, to an extent so drastic that they kill all social life. Local Transport Areas
    People have a fundamental yearning for great bodies of water. But the very movement of the people toward the water can also destroy the water.  Access to Water
    Rooms which are too closed prevent the natural flow of social occasions, and the natural process of transition from one social moment to another.  And rooms which are too open will not support the differentiation of events which social life requires.  Half-Open Wall
    Cooking is uncomfortable if the kitchen counter is too short ... ... and also if it is too long. Cooking Layout

    Traditional Programming

    Avoid GOTO (GOTO considered harmful)
    Avoid executing data
    Avoid hard-coding data into program

    Structured Modelling

    Unresolved many-to-many relationships
    Many-valued attributes
    Singular types
    Double V

    Distributed Systems Engineering

    Avoid single point of failure
    Cycles lead to deadlocks
    Take no small slips
    No central authority over software design or configuration Federation (RM-ODP)
    No visibility of implementation or location details Transparency (RM-ODP)
    Minimize Use of Interrupts Run to Completion

    OO and Component-Based Development

    Globals Considered Harmful (Desmond D'Souza)
    Hyperspaghetti Objects and Subsystems Decoupling
    Don't Interrupt an Interrupt
    Avoid inhibiting garbage collection Weakling, Weak Collection
    Avoid excessive initialization overhead Lazy initialization
    Explicit Invocation - Tight Coupling EventPorts (Lauder & Kent)
    Implicit Collaboration Protocols - Code Pollution EventPorts (Lauder & Kent)

    Organization Design

    Don't make technical staff do documentation Mercenary Analyst
    Unscrutinized relationships between roles can lead to undesirable coupling at the organizational level. Move Responsibilities
    Avoid distractions Sacrifice One Person
    Avoid retreat from boundaries. The Psychodynamics of Organizations (Larry Hirschhorn)
    Adding resources to a project that is running late merely makes things worse. Mythical Man-Month (Fred Brooks)
    Heroic programming is not a sustainable business practice UML
    Mushroom management mushrooms

    Other Sources


    Author details


    home page

    contact us

    This page last updated on May 29th, 2001
    Copyright © 1996-2001 Veryard Projects Ltd