Anti-Pattern
An anti-pattern (from the English , translated as anti-pattern ) is a generic term for patterns of behavior that especially in software development to be found and mostly general to organizations are transferable. Approaches to solutions that are unfavorable or harmful to the success of a project or an organization are called anti-patterns. They form the counterpart to Pattern (English pattern ) representing good and proven problem-solving approaches.
The concept of patterns was best known through the design patterns from the 1994 book of the same name . These each include a description of a prototypical problem situation including a proposed solution. After patterns were used increasingly successfully in software development, negative examples were also discussed in order to identify and document recurring errors and to point out measures for remedying them. Just as patterns are not limited to the design of software and there are also catalogs for analysis patterns , architectural patterns or organizational patterns , anti-patterns are also not limited to the source code and software architecture , but often have project management and company processes as their subject.
As a rule, anti-patterns arise from inadequate experience or a lack of qualifications. One can also observe the conscious use of anti-patterns in order to achieve a specific purpose that deviates from the actual project goal for one's own benefit.
Categorization
Meanwhile, the occurrences of anti-patterns are differentiated more and more finely. They fan out from pure software programming (this is also referred to as code smells , which can be removed by refactoring if they exist and are identified ), move on to architecture and design , work in project management and in corporate processes and organization as well as in management . In addition, so-called meta-patterns can be identified more frequently in practice. These combine individual patterns into new, more abstract patterns or introduce further dimensions or more abstract categorizations.
Project management anti-pattern
Clutter
The dazzle work (English smoke and mirrors ) denotes not finished functions, which are simulated as finished.
Bloated software
Bloated software describes software that is bloated with unnecessary additional functions or wasted resources and thus hardly or not at all improves the actual application.
Feature creep
Feature creep ( creep start functionality ) called it when the amount of functionality to be developed in a project plan is held, it is but continuously expanded.
After creating the project plan, the customer tries to incorporate further functionality in the version. This leads to problems if the version being worked on does not have the necessary design, deadlines cannot be met, or the real costs grow beyond the planned costs.
This is very dangerous in heavy-weight processes . With lightweight processes such as Extreme Programming (XP), the consequences must be clear to everyone involved. Systematic requirements management and change management are mandatory. Certain changes to the project plan during development are difficult to avoid in larger projects, because working out the specifications down to the last detail is usually more time-consuming than planning a little reserve. Requirements can also only be discovered during development.
Extreme, malicious and grossly negligent use of this pattern can be motivated by the fact that the client, who is always demanding new functionality, wants to boycott the product and tries to prevent its completion, or he deliberately suppressed the functionality actually required in the planning in order to find a cheaper one Receive an offer.
A play on words, the content of which includes the change from creeping feature to feeping creature , expresses the fact that requirements and implementations have become unnecessary or do not fit into the overall concept of performance features.
Scope creep
The scope creep ( creep in further areas of application ) is similar to the feature creep , but not related to functionality, but to the area of application. Here, too, the client is characterized by the fact that he wants to expand the scope of the software in a clever and hidden manner without explicitly admitting this. Example: areas of application that have not been discussed are suddenly very important or the lack of an area is even shown as an error that urgently needs to be rectified.
Brooks Law
The Brooks'sche law states that a herhinkendes behind schedule project takes longer when new employees are hired because the new employees will need time to learn the ropes and she brake the established colleagues.
"Adding manpower to a late software project makes it later."
"Adding employees to a delayed software project only delays the project further."
Death Sprint
With a Death Sprint ( Overheated Project Plan ), software is deployed iteratively . The provision takes place in a much too short period of time. On the outside, the project looks very successful at first, as new versions with new properties are always being completed. However, the quality of the product suffers both externally and technically, which only the developer recognizes. The quality decreases with every "successful" new iteration. Counterpart to Death March .
Death March
A death march ( death march ; occasionally suicide mission ) is the counterpart of an overheated project plan. A death march project drags on forever.
In an optimal case, advance versions are provided, but they are of poor quality. The failure is objectively visible. No milestones can be kept or none exist. In the worst case, one of the consequences of this is that the project is no longer a project, but just a sequence of activities that is not completed in time. There are no specific commitments for dates and delivery of properties.
A death march project can also be consciously accepted in order to divert attention from deficits in the organization and to delay developments, i. H. to develop something until an unspecified property works subjectively in some form. If both requirements management and change management are not in place and the project is no longer a project, the development product dangles around without orientation and its quality steadily decreases.
A death march project can also be combined with an overheated project plan (see above) in order to distract from the lack of planning and deficits in organization and technology. Functionality is then presented as new, which has already existed for a long time, or there is no control instance that assesses the necessity, relevance, form, correctness and importance of the functionality provided.
- example
- New requests from yesterday are ( not : include!) The bugs of tomorrow.
A death march project often occurs when there are no stakeholders who are interested in the product, or when the effort that goes into the product or even the whole product ultimately has no meaning / importance. In this case, the company or the development department often deals (with) itself.
Architecture or design anti-pattern
Big Ball of Mud
Software that is no identifiable software architecture has, is as big ball of mud ( Large mud lumps called).
Gas factory
As gas plant (English gas factory ) derogatory unnecessarily complex system designs for relatively simple issues are known.
God object
The terms god object (English god object ), God class ( God class ) and Blob describe an object that knows too much or does. The division into responsibilities, encapsulation and adherence to design patterns help to counter this pattern.
Inner platform effect
The interior platform effect (English Inner platform effect ) occurs when a system has such a broad configuration options that it ultimately becomes a weak copy of the platform by means of which it was built. One example are data models that dispense with specific (application-related) database tables and instead implement a separate management layer for the data structure using general tables with the actual goal of increasing flexibility. However, such systems are typically difficult to master and often suffer from additional performance problems.
Spaghetti code
Spaghetticode is a very compact system structure, which is characterized by jump commands whose control flow is similar to a pot of spaghetti. The code resembles a monolithic block and is particularly poor in maintainability and reusability.
Sumo wedding
As sumo wedding (English Sumo Marriage ), it is referred to as a fat client unnaturally strongly dependent on the database is.
A lot of logic is positioned in the database in the form of the database's own programming language . For example in Oracle with the programming language PL / SQL . The whole architecture is therefore very inflexible.
If the application is to be migrated to an Internet application or the database is to be changed, many areas must be redeveloped on both layers ( client and data management ). The systems are not decoupled .
Integration database
An integration database is a database that is used directly by several applications to ensure synchronization between the applications.
“Integration databases - don't do it! Seriously! Not even with views. Not even with stored procedures. "
The alternative to an integration database is a shared database . This is a database that is accessed by a single web service. The web service provides the functionality of the database in the form of a REST or SOAP interface and can be used by various applications.
"Take it up a level, and wrap a web service around the database. Then make the web service redundant and accessed through a virtual IP. Build a test harness to verify what happens when the web service is down. That's an enterprise integration technology. Reaching into another system's database is just… icky. "
Programming anti-pattern
Double-checked blocking
Inexperienced developers often implement as defective be regarded double checked locking (English double-checked locking ). This is considered an anti-pattern.
onion
When onion (English Onion ) refers to program code in which new functionality to (or above) the old is laid.
Often times, onions arise when a developer is asked to add to a program that they did not write. The developer does not want to or cannot fully understand the existing solution and simply puts his new solution over it. With a multitude of versions and different developers, this leads to an onion system over the years.
Copy and paste
Programming by means of copy and paste (English copy and paste programming ) describes it when the programmer does not develop the code from scratch, but uses existing source texts from which he copies passages.
The risk here is very high that he copies errors as well or the copy is not optimally ready for use in the new area. The developer reflects less on his program than if he developed each line himself. This is an error-prone procedure if the developer does not know what he is actually doing. The maintainability of the code is reduced if (almost) the same program code occurs in many places. Instead of copying, a common function should be envisaged.
Lava flow
A lava flow (English Lava flow or Dead Code ) describes the fact that more and more "dead source code" is lying around in an application. This is no longer used. Instead of deleting it, more and more branches are built into the program that run around the said source text or are based on it. Redundant code is the umbrella term for dead code. It contains in addition to the dead code ( English dead code ) (executed code, the result is never used) also unreachable code ( English unreachable code ), which is code that due to the sequence control never run reached in any possible execution of the entire program and therefore can be. The term dead code is often used synonymously with redundant code.
Magical values
In Magic values (English Magic Values ) is, to data ( literals ) with special meaning. They are hard-coded (English hardcoded ) and should be seen with special knowledge of the specific use. Such values should be defined centrally as a constant or variable, ideally as a type-safe object.
public class Bar {
public static void main(String[] args) {
Bar bar = new Bar();
bar.go(7); // hart codierter Wert
}
public void go(int param){
switch(param) {
case 1: System.out.println("a"); break;
case 3: System.out.println("b"); break;
case 7: System.out.println("c"); break;
case 12: System.out.println("d"); break;
default: System.out.println("x"); break;
}
}
}
Reserved words
Using reserved words, such as in SQL statements, can lead to hard-to-find errors. Replacing a manufacturer's database with another product can result in additional names having to be considered reserved. This can be counteracted by consistently providing identifiers and character strings with appropriate start and end markers (e.g. quotation marks).
Unintentional Complexity
As Unintentional complexity (English Accidental complexity ) is called a programmed solution which is more complex than it would be required to be solved and appropriate for that. This anti-pattern is related to the gas factory .
Organization, management and process anti-patterns
Miracle Weapon
A miracle weapon (English golden hammer ) is a preferred solution that is regarded as universally applicable.
"If all you have is a hammer, everything looks like a nail."
"If you only have a hammer, everything looks like a nail."
Reinvent the wheel
By reinventing the wheel (English Reinventing the wheel or not invented here syndrome ) is the steady rebuilding of software - without existing solutions or frameworks to use - called. Since there is no reuse, the development effort increases, which leads to immature and more expensive software (compared to the use of the existing software).
Reinvent the square wheel
With the square reinvent the wheel (English Reinventing the square wheel ) refers to the provision of a poor solution when a good solution already exists.
Body ballooning
In body ballooning , the supervisor acts exclusively out of the endeavor to expand his position of power, which is defined either from the corporate structure or purely subjectively from the number of employees. This can lead to the supervisor consciously preferring more labor-intensive solutions and working techniques to efficient ones.
Empire building
By means of factually incomprehensible and constructive measures, a single person tries to expand or maintain their power. This can be body ballooning , but also the constant blaming of others, especially those who no longer work for the company, the execution of pathological politics, discrediting , bullying and other facets that only aim to strengthen their own position or the to keep one's own status. This pattern is also characterized by the fact that the person avoids taking responsibility and knows how to prevent written evidence of occurrences and decisions. Thus, it does not have to be measured by these, which also makes it easier to simply delegate the responsibility for the failure of a project to another person. Here, preference is given to choosing someone who has actually only implemented the decisions (like a programmer who implements the decisions of the superior or a project manager implements the customer's requirements).
Warm corpse
A warm corpse (English hot body ) refers to a person who makes a dubious or no contribution to a project.
Single head of knowledge
A single head of knowledge is an individual who is the only one who has knowledge of software, a tool or another medium used throughout the company. This often shows a lack of knowledge management , a lack of exchange between colleagues or deficits in the organization, but it can also have been consciously striven for by the individual.
When the individual leaves the company, metaphorically speaking, they take the knowledge with them, which is very dangerous for the company. The company is bleeding metaphorically from ( bleeding ).
The pattern can be prevented by suitable measures. For example through development after XP and team building events together with employee loyalty, motivation and promotion of identification with the company in order to minimize fluctuation. Proper documentation to which all affected employees have access prevents a single head of knowledge .
Mushroom management
With mushroom management , employees are kept uninformed and small. The following principle applies accordingly:
"Keep them in the dark and feed them full of shit."
"Leave them in the dark and feed them shit."
Development and self-realization hardly take place in mushroom management . The analogy of the workforce to a mushroom field is characterized by the fact that the employees are visually covered with dung and kept in the dark and, if they have grown too big (too much experience, too good performance, etc.), made small, put under pressure or even be fired. This association also implies that the management makes decisions without consulting the specialists or does not inform the workforce about these decisions. Often it can also be observed that the management does not know the individual abilities, strengths, weaknesses and roles of the team members and sometimes even does not want to know (people are brought into line: Admitting that someone can do more than the others makes them more powerful, which is avoided shall be).
One more meeting will solve it
One more meeting will solve it ( Yet Another Meeting Will Solve It ) is when a meeting is called in a project that is delayed (i.e. a project with a delay), which only increases the delay.
Net Negative Producing Programmer
A net negative producing programmer is an underperforming, unproductive developer. Removing this one from a team can do more to increase project productivity than adding a good developer and leaving the unproductive one.
Management by numbers
Management by Numbers (English management by numbers ) is an allusion to painting by numbers . In management by numbers, there is an excessive emphasis on quantitative management. Especially when the focus is on cost while other factors such as quality are neglected.
In this pattern, programmers will be happy as a "commodity" (English commodity seen) and regarded as interchangeable. This is a very short-term way of thinking that does not take into account that a lack of employee motivation or employee fluctuation can result in significantly higher costs for the company in the medium to long term than a short-term investment in these.
The term software factory should also be mentioned here, an attempt to automate software development and to regard the programmer as an interchangeable production factor. However, this does not take sufficient account of the fact that software development is to a large extent a creative, artistic process that requires freedom and, ideally, a high degree of development and (ideally intrinsic ) motivation on the part of the developer. It is also important to consider that employees gain a lot of experience working on a product over time, which the company loses to a large extent if the person leaves the company.
Fear of success
Fear of success (English Fear Of Success ), and atmosphere of fear refers to it when the management of a frightened, defensive atmosphere. This is like a soccer team that only defends its own goal without trying to score a goal itself.
In a culture full of fear, hardly anything constructive can arise. Even people who create something good break off their project because they assume that they will lose anyway or that the good solution will not be rewarded or presented as bad.
Companies under fear appear paralyzed and fail to actively approach new markets and solutions. Entire companies as well as departments or individuals lose their competitiveness . Fear of attracting attention through success and thus attracting the suspicion of colleagues or management also prevents employees and companies from reaching their full potential. It is not uncommon for bad managers to see a danger in very good employees, as they are competition for their position.
Typical statement: “I do this secretly. It's the best solution, but I don't want the boss to know about it. "
Wrong system architect
A fake system architect ( Faux System Architects ) can arise when management realizes that there are big differences in the skills of the programmer. The management selects a person who has supposedly overwhelming skills, for example in software development as well as in dealing with people - especially with people whose qualifications are below average.
The person is deployed with high expectations from the management and is often an architect , but often another professional superior. In-house specialists are not asked to make the selection, rather the management decides for itself and alone, although it is difficult to decide for itself whether someone is a good software developer.
For a long time, this also works quite well, as the supposed expert can sell himself quite well and also knows how to express himself verbally very skillfully. Over time, however, it becomes increasingly clear that expectations of the architect were too high. On the one hand because of the failure to improve the software or the consistently poor quality of the bad programmers, on the other hand because of the dissatisfaction of the good programmers. He cannot fulfill the flowery, almost blind expectations of him. When assessing the system architect, it is particularly important to consider the project as a whole. The consistently poor quality of poor programmers can very well be due to circumstances that even a good system architect cannot foreseeably influence. Depending on their position, good system architects can also be victims of body ballooning or empire building (see above). A good system architect will e.g. For example, do not try for weeks or months to improve the quality of bad programmers if there is no foreseeable potential for them. Unrealistic framework conditions given by poor management degrade and A. Also the best system architect. If such circumstances are known, but the system architect still shows no signs of leaving the company, it could actually be a bad system architect.
Crocodile management
With crocodile management , the project manager is only partially present in the project and only takes care of details that the project employee has not dealt with. With regard to the behavior of a crocodile, that of the project manager is characterized by:
- Pop up
- Open your mouth
- submerge
Programmer interrupt
A programmer interrupt occurs when the programmer is interrupted while he is working. This includes statements from colleagues, emails, upcoming meetings and the like. Studies have shown that a programmer needs between 10 and 15 minutes after an interruption to be able to continue working effectively, but is only given the opportunity to work for more than two hours without interruption about once a day. The interruption is all the more serious, the higher the mental strain on the programmer during his activity.
Interruptions are particularly problematic here
- while editing several code sections at the same time,
- during search activities for programming problems,
- while thinking through the program flow; especially with parallel code,
- which causes the developer to lose sight of the integrated development environment .
Developers typically try to counteract possible interruptions with headphones , closing the e-mail program and sometimes switching off the mobile phone . In addition, developers use methods in order to be able to familiarize themselves again as quickly as possible, these include to-do lists , deliberately caused compilation errors ( e.g. through module tests ) and sticky notes .
However, interruptions in the workflow can be observed not only with developers, but with all office workers.
Further
Meta-pattern
Programmer Experience Clumping
Inexperienced programmers are usually willing to work for a company for a relatively low salary (e.g. out of ignorance or in order to gain experience there). In such companies, the programmers are often not valued by the management (mostly in companies where management by numbers predominates). There are bad working conditions. The inexperienced programmers cannot develop any further.
Experienced specialists see what is happening and can assess it objectively and critically. They will switch jobs to take on a challenge that better understands programming and recognizes good work. This produces a grouping effect in which inexperienced programmers group or stay in the company and the experienced people group elsewhere. There is high fluctuation, with more and more good people leaving the company.
Without the guidance of experienced colleagues, inexperienced developers or newly hired rookies cannot improve. A vicious circle arises, which is also intensified by the fact that the employer sends his (supposedly less loyal) employees to less and less training, because he is afraid that people will leave the company anyway and the money would be badly invested. At some point, nobody in the company knows what an experienced, good developer looks like or the benchmark is missing : the inexperienced developers notice less and less that they are actually inexperienced.
Programmer Experience Clumping is not limited to programmers; non-IT departments can also be affected. A derivative of the anti-pattern is that the good people stay in the company for convenience or other personal reasons, but reduce their enormous productivity so that they are only a little bit better than the bad employees. Since this is enough to set yourself apart and secure your position, the good employees are by far not exhausting their potential. Ultimately, this is very worrying for everyone involved, but above all for the company.
decomposition
A decomposition (English Corrosion ) describes the intentional or unintentional use of a multitude of anti-patterns from all areas. This goes hand in hand with a consistent defense of the procedure, is mostly irrelevant, brutal and without discussion. One inevitably comes to the conclusion that the user would like to damage the company or the software product through gross negligence or prevent its successful, inexpensive introduction. This can also be motivated by the fact that the user wants to harm another involved party.
literature
- Frederick P. Brooks: The Myth of the Man Month: Essays on Software Engineering . mitp, Bonn 2003, ISBN 3-8266-1355-4 .
- William J. Brown et al .: Anti-patterns. Refactoring Software, Architecture and Projects in Crisis . John Wiley & Sons, New York 1998, ISBN 0-471-19713-0 .
- Martin Fowler: Refactoring: Improving the Design of Existing Code . Addison-Wesley, Reading / Massachusetts 1999, ISBN 0-201-48567-2 .
- Joshua Kerievsky: Refactoring to Patterns . Addison-Wesley, Boston 2004, ISBN 0-321-21335-1 .
- Bruce A. Tate: Bitter Java . Manning, Greenwich / Connecticut 2002, ISBN 1-930110-43-X .
- Bruce A. Tate et al .: Bitter EJB . Manning, Greenwich / Connecticut 2003, ISBN 1-930110-95-2 .
- Gerald M. Weinberg: Psychology of the programmer . mitp, Bonn 2004, ISBN 3-8266-1465-8 .
See also
- Counterexample - word with a similar meaning, also in other specialist areas
Web links
- Anti-Pattern Definition, Portland Pattern Repository (English)
- Anti-Pattern Catalog, Portland Pattern Repository (English)
- Bruce Eckel: Programmer Experience Clumping and Faux System Architects (English) ( Memento from February 4, 2010 in the Internet Archive )
Individual evidence
- ↑ Frederick P. Brooks, Jr .: The Mythical Man-Month . Addison-Wesley, 1995 [1975].
- ↑ Guido Stepken: Anti-Patterns in Software Development . (PDF; 315 kB)
- ↑ a b Michael T. Nygard: Release It! Design and Deploy Production-Ready Software . O'Reilly, 2007, ISBN 978-0-9787392-1-8 , Dependencies between Systems: Databases (English, 326 pages).
- ↑ AW Appel: Modern Compiler Implementation in Java . Cambridge University Press, 1998
- ↑ The Psychology of Science: a reconnaissance ; English; by Abraham H. Maslow , first published in 1966 ( First Edition, January 1966 ) through HarperCollins- Verlag; 168 pages; ISBN 0060341459 ( ISBN -10), ISBN 978-0060341459 (ISBN-13), see also on Amazon.com (accessed on January 31, 2020)
- ↑ mushroom management. In: Urban Dictionary . Retrieved January 31, 2013 .
- ↑ YetAnotherMeetingWillSolveIt. In: wiki.c2.com. April 17, 2011, accessed January 7, 2018 .
- ↑ Harold S. Geneen: The case for managing by the numbers . Ed .: Fortune. tape 110 , no. 7 , 1984, pp. 78-81 .
- ↑ Programmer Interrupted. Ninlabs Research, January 19, 2013, accessed February 8, 2013 .
- ↑ Chris Parnin, Spencer Rugaber: Resumption strategies for interrupted programming tasks. (PDF; 407 kB) August 10, 2010, accessed on April 6, 2016 (English).
- ↑ Shamsi T. Iqbal, Xianjun Sam Zheng, Brian P. Bailey: Task-evoked pupillary response to mental workload in human-computer interaction. 2004, accessed February 8, 2013 .
- ↑ James Fogarty, Andrew J. Ko, Htet Htet Aung, Elspeth Golden, Karen P. Tang, Scott E. Hudson: Examining task engagement in sensor-based statistical models of human interruptibility. 2005, accessed February 8, 2013 .
- ^ The hidden cost of interrupting knowledge workers. October 5, 2009, accessed February 8, 2013 .