Antipatterns are closely related to another important software concept: Design patterns, which document recurrent solutions.
A Design pattern becomes an Antipattern when it causes more problems than it solves.
In a normal Design pattern there is a problem and a solution. The essence of an Antipattern is two solutions. The first solution is problematic. It is a commonly occuring solution that generates overwhelmingly negative consequences. The second solution is called the refactored solution. The refactored solution is a commonly occuring method in which the AntiPattern can be resolved and reengineered into a more beneficial form.
Build your own nightmare: All patterns have consequences. There are situations when a pattern is a good solution, and other situations when it becomes an Antipattern. A design becomes an Antipattern when it causes more problems than it solves.
Software gurus will tell you that you just need a new method, new tools, more training and more consultancy - and you will be home free.....
The Antipattern approach on the other hand is more about using commonly occuring examples from both management and development to teach better practices.
Below follows a list of important Antipatterns (see the book for a full list) from (IT) management and software construction.
---
The Avarice (m) antipattern: Architectuel avarice means the modelling of excessive details, which results in excessive complexity due to insufficient abstraction. Excess complexity leads to many software problems. Overly complex systems are expensive to develop, test and maintain. In the worst cases, development steps are skipped (such as test) in order to make up for lost time.
Pride (m) antipattern: The sin of pride is the ''not invented here'' syndrome. Reinvention involves many unnecessary risks and costs. New software must be designed, coded and debugged. Integration of commercial packages and freeware will in many cases perform better.
The complexity (m) antipattern: Management of complexity is important at all levels. Project management and architecture management must have a complexity policy. At higher scalability levels complexity becomes exponentially worse.
The not taking responsibility (m) antipattern: Management should ask the following questions 1. What is the problem. 2. What are other people doing to solve the problem. 3. What are you doing?
This should gather information and build awareness of individual responsibilities. The first step is of course to recognize that there is a problem. Along with clarifying alternatives.
The mushroom management (m) antipattern: In some management circles there is an explicit policy to keep system developers isolated from end users. Requirements are passed, second hand, through intermediaries to developers. In mushroom management user acceptance is at risk, as changes to requirement and understanding of requirement will not be resolved before delivery.
Requirements are not understood by end users, and rarely to full extend by developers. So in reality noone understands the functionality before delivery. Prototyping and breaking the mushroom pattern will solve the problem.
Vendor lock in (m) antipattern: "What you see is - sort of - like what you get" ("weasel wig"). Isolation layers are needed in code to deal with vendors.
Mythical man months (m) antipattern: Ideal project is 4 man in 4 month. Beyond that you have escalating problems with group coordination.
Design by committee (m) antipattern: People talk and work serially. When there is a single thread of discussion, most people are not productive most of the time. Architects and developers have conflicting interpretations of the design. Design becomes significantly over budget and overdue. Concerns are not separated and reference models are not used.
Abstractionists vs. Implementationists (m) antipattern: Programming skills do not equate to skills in defining abstractions. There appear to be two distinct groups involved in software development. Abstractionists and their counterparts the implementationists. The implementationists dont deal with the abstract level - what do we want to solve - whereas the abstractionists are not comfortable with the implementationists detail level.
Intellectual violence (m) antipattern: IV occurs when someone who understands a theory, technology, or buzzword uses this knowledge to intimidate others in a meeting situation. It is the responsibility of management to make sure that this doesn't happen. When IV is pervasive, a defensive culture arises, which inhibits productivity. People control and conceal information instead of sharing it.
The email (m) antipattern: Email is an important communication tool. Unfortunately emails are inappropriate for many forms of communication dealing with sensitive matters. Used excessively it becomes SPAM. Expect all emails to go directly to your worst enemies and toughest competitors, especially those labelled "confidential".
The detalitis plan (m) antipattern: Inability to plan at appropriate level. The objective shifts from delivery of software to delivery of a set of plans. Management assumes that because effort and cost are tracked, progress must be equivalent. In fact there is no direct correlation.
Irrational management (m) antipattern: Managers need to understand both the technical skills and personal traits of their staff members. Solutions should identify the key players. Collect evidence from all involved. I.e. make sure all voices are heard and identified. Confirm that solution options are understood by ALL affected. Involve the concerned staff in implementing the solution when possible.
Be aware that the rational choice might not be the choice that managers and customers will accept.
If an important bias was not reflected in the decision analysis, then all decisions should be re-evaluated and all parties should be reinformed based on this new information.
The blob (s) antipattern: Where one class monopolizes the processing. An absence of object oriented design. Lack of (any) OO architecture.
The functional decomposition (s) antipattern: Classes with such names as "Calculate_Interest" or "Display table" may indicate this pattern. No way to clearly document or (even) explain how the system works. Typically a specified disaster, where architectual commitments are made prior to requirement analysis.
The golden hammer (s) antipattern: Occurs when one developer uses a favourite software concept obsessively. For example, some developers learn one or two of the GOF patterns and apply them to all phases of software development.
The spaghetti code (s) antipattern: Is the classic antipattern. The flow of execution is dictated by object implementation, not by clients of the objects. Follow on maintenance efforts contribute to the problem.
The cut and paste (s) antipattern: The same bug reoccurs throughout software despite many local fixes. The context or intent behind a software module is not preserved along with the code.
Risk management (s) antipattern: Risk becomes unacceptable through lack of adherence to 1. Coding standards 2. Code reviews 3. Test planning 4. Unit testing 5. API testing 6. Integration testing 7.Feature testing 8. Program documentation.
Throw it over the wall (s) antipattern: The code is finished - no testing, no documentation.