|
design pitfalls as negative patterns |
|
refactoring (bad smells)
negative patternsI'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. |
Note: some people refer to these as antipatterns.
Pattern Matching / Tool Support
In some cases, it may be possible to provide automated or semi-automated replacement. Perhaps some kind of wizard to replace/correct identified negative patterns.
We would like to see design tools built with proper capability for user-defined negative patterns. There are many tools that allow general search enquiries against the repository; thus if you can express the negative pattern in the appropriate enquiry language, then you can create search macros. But these are usually not integrated into the tool itself.
Develop quality metrics for design, based on the presence or absence of defined patterns.
It's useful to know how widespread is the pattern in the legacy system. A pattern may be recurrent in a legacy system - it appears in many places. Sometimes the same pattern may be benign in some places, and malignant in others. Or it may be pervasive - it appears almost everywhere. A recent example of a pervasive and malignant negative pattern is the use of two-digit year fields - the so-called Year 2000 problem.
This kind of paradoxical intervention is common practice among family therapists and marriage counsellors, who sometimes provoke couples to fight, not just to observe exactly how and when they do fight, but also in the hope that this will help them find ways of not fighting. Or a personal therapist, who encourages an overweight client to gain even more weight, in the hope that this will create a level of awareness and self-control that will result in weight loss.
Quality and testing methods often include the related idea of fault seeding, where defects are deliberately inserted, as a way of measuring the effectiveness of quality and testing procedures.
In order to use these techniques safely, your configuration management and release management procedures need to be good enough to guarantee that the defective items don't get released into production. Or perhaps your software is already so bad, that a few more defects won't make much difference!
Another danger of this technique is that some people may start to regard the whole concept of negative patterns - or patterns generally - as a bit of a joke.
| 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.
| 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. |
| Applicability
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? |
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.
Definitions don’t matter
|
The goal is the process.
What matters is the way we work with patterns
|
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 |
| Avoid GOTO (GOTO considered harmful) |
| Avoid executing data |
| Avoid hard-coding data into program |
| Unresolved many-to-many relationships |
| Many-valued attributes |
| Singular types |
| Double V |
A tool called Validator has been brought to my attention, which checks a data model for more advanced negative patterns, but I haven't yet had an opportunity to test it out.
| 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 |
| 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) |
| 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 |  |
I have done some work on the pitfalls of technology transfer and the pitfalls of knowledge management. I have also identified some patterns of poor scholarship.
Fraud can be regarded as a negative pattern for business.
| top |  |
|
Copyright © 1996-2001 Veryard Projects Ltd http://www.veryard.com/sqm/pitfalls.htm |
