Development of Antipattern Reference Model

Abstract

 In this modern word, pattern reliability is a huge challenge to the software engineering industry. Hence, antipattern becomes a determination as being the effective and objective instrument to evaluate any design. Antipatterns and patterns are great tools or instruments in the hand of a software designer.  Antipatterns and patterns are powerful instruments for improving the quality of software systems. 

Anti-patterns efficiently map general situation or problem to a specific class of solutions which is the refactored solution. Antipatterns are closely related to design pattern because both are aimed at providing solution to reoccurring problems. An antipatterns is a common response to problems that appears to be reoccurring with ineffective solutions and risks evaluated to be highly counterproductive. The main purpose of Antipatterns are: to help identify problems in software development and to help implement the solutions to such problems. In antipattern, understanding the problem is the first step to recovery because solutions will not be effective or usable without a state problem to solve. There are consequences with all patterns and sometimes, there are instances when a pattern is proven to be an effective solution to a problem and other instance when it becomes an antipattern. This paper focuses on antipattern reference model, types of antipatterns, and the list of harmful practices that represent antipatterns in the implementation of software development process.

   Introduction

The goal of software development is to generate products which has high level quality, and this can be achieved when the level of productivity and efficiency is high. To arrive at this state, it is important to avoid the bad software design practices. A perfect design pattern is an important issue in software engineering. Patterns presents many advantages when used in software development. Advantages of using patterns in software development are: improvement in code standards, reduce time consumption, and scalable design. Undoubtedly, the key to a successful software design is the use of patterns without formal problems. It is pertinent to know that it is very necessary to avoid the risks introduced into software development by bad practice of software. Sometimes, these anti-patterns are labelled as the bad practice and it occur in different areas. The catalog anti-patterns is an important road map, mostly on the area that seem to appear as the dark path that might be followed when necessary precautions are not taken, and of course without a doubt causes problems in projects. Since antipattern could sometimes be termed as a bad practice depending on the usage, can often result to poor software design because antipattern are caused by poor abstraction and poor implementation of the theoretical approach of software.

Get Help With Your Essay

If you need assistance with writing your essay, our professional essay writing service is here to help!

Essay Writing Service

Regardless of the bad parts of antipatterns, they are also useful in several ways. They can save software projects in trouble as they describe preventive measures as well as the refactored solutions. They are also useful in helping to detect problems in the code, the architecture and the management of software projects. Lastly, they provide a common vocabulary for known dysfunctional software designs and solutions.

All software developers should have good management of time because if time becomes a factor for developers, it can hinder them from having the thought of a good practice and patterns could become antipatterns if developers abuse pattern implementation. Design patterns consist of a problem and solution while antipattern consist of two solutions. One of these solutions is problematic and the other is refactored solution which is more beneficial. The diagram below depicts design patterns and antipatterns in software lifecycle.

AntiPatterns Reference Model

Antipattern models are being differentiated from every other forms of software development knowledge as they are being documented using a rigorous and consistent reference model.

The purpose of a design pattern is a problem and solution. The problematic part of the design pattern is expanded to the context and applicable design forces while the solution part of the design pattern is resolving any design force that might arise in way that generates some benefits, consequences, and a follow up problem. For a pattern to be considered a pattern, the solution provided has to be observed at least three times as no three occurrences can be identical, and the design pattern is an abstraction of these experiences as shown in the figure above.

Antipattern compared to the regular design pattern has two solutions; one which is the problematic solution and the other is the actual solution called the refactored solution. What differentiate the two solutions provided by antipattern is that the problematic solution is a commonly occurring solution that generates a negative consequence while the refactored solution is a commonly occurring method that can be resolved and reengineered into a more useful and beneficial form.

Viewpoints

Antipatterns can be seen from three major viewpoints which are the software developer, the software architect, and the software manager. These three viewpoints listed corresponds to the three types of antipatterns which are:  development, architectural, and the project management antipatterns. The development antipattern describes the problems or situations encountered by the programmer when solving programming problems. The software architectural antipatterns describes likely problems that may arise in the system structure, their consequences as well as their solutions. Finally, the project management pattern which can affect other antipatterns severely serious unresolved problems occurs. Therefore, the project management patterns have the most serious unresolved problems in the software systems as this can affect the all the people in the software roles, and hence directly affect the technical success of the project. These three types of antipatterns will be discussed more in details later on this paper.

To provide a better explanation of this topic, it is going to be discussed from three different perspectives which corresponds to the reference models and these are the root cause, the primal force, exceptions, and the refactored solutions. The root cause describes possible cause of the antipattern, primal forces describe what motivates the decision making and the SDLM defines the architectural scales.

Root Cause

The root cause defines the mistakes made in the software development that results in unfulfilled business needs, cost overruns, failed projects, and schedule slips. Statistics from most software industry show that 1/3 of projects are cancelled and 5/6 of software projects are unsuccessful. There are seven root causes of antipattern and this will be discussed individually.

Haste

 From the popular saying that haste makes waste is a very common thing that happens in the software industry mostly due to rapid changes in the project schedules. Poor quality of software could be as a result of hasty decision. Often times, project managers find themselves in a state of dilemma that makes them to cut down budgets and schedules to make unrealistic targets due to severe schedule related issues. As a result of hasty decisions, important parts of the software development life cycle are sacrificed in order to meet up with the schedule. At this point, any work is considered acceptable and ready for delivery and the testing phase of the software development life cycle is a usual victim of this. In this environment, long term architectural benefits are sacrificed for experience. Quality, object-oriented architecture is the product of careful study, decision making, and experimentation. Object-oriented architecture comprises a set of high-quality design decisions that provide benefits throughout the life cycle of the system [2]. However, making hasty decisions can ruin the quality of the projects, hence never make the mistake of making an object-oriented architectural decision hastily.

Apathy

 This root cause is very common with developers who thinks that they know too much. They are unwilling to attempt a known solution that is reliable, hence, not caring about solving known problems. Apathy about object-oriented architecture leads to lack of partitioning as it is one of its key aspect. The critical partitioning decision in object-oriented architecture is between stable reusable design and replaceable design. The stable reusable design remains with the system throughout its life cycle as individual software modules are modified, replaced, and added. Neglecting this critical partitioning can result to negative consequences because the core of the architecture must change in response to change levels in the subsystems. Apathy leads to poor support for and poor partitioning architectures makes an application interoperability and reuse difficult.

Narrow-Mindedness

 This is similar to apathy. There are some solutions that have been proven to work correctly but developer with this type of problem will refuse to acknowledge use that solutions because they are simply unteachable. Therefore, narrow-mindedness is just the refusal to practice solutions that are proven to be effective.

Sloth

 Ease is a greater threat to progress than hard work. Sloth is a result of laziness found in developer or manager who makes poor decisions based upon an answer that looks easy. Application developers can easy and quickly define the system-level interface using the ISO Interface Definition Language enabled by the Distributed object technology. Conversely, the ease of system-level definition can lead to disaster or simply sloth because the automatic generated interface will lack configuration. The more changes made to the interface, the more it will become unclear to developers, making them to spend more time trying to understand how the system works. Proper interface configuration, effective documentation, and reduced software obsolescence are ways to counter this problem.

Avarice

 Systems ought to be designed as simple as possible because excessive complexity leads to may software problems and project challenges making the system expensive to develop, integrate, test, document, maintain and extend. In an extreme case cases, some of the development phase such as the testing are skipped which can quickly lead to project failure.

Ignorance

 This is an intellectual sloth. This keeps people stupid because they failed to seek understanding which eventually leads to long-term software problems. The consequences of ignorance often occur in the migration of applications to distributed architecture. In ignorance, one assumes that existing definitions of application objects would produce the same result when system-level interfaces are extracted from it.

Pride

 Pride goeth before the fall. The sin of pride is the not-invented-here syndrome. There are tons of reusable codes that the developer could have been able to use but because of pride they want to unnecessarily invent new designs which would involves many unnecessary risks and costs.

Types of Antipattern

 There are three types of antipattern and they are development antipattern, architecture antipattern, and project management antipattern. All these antipatterns will be discussed in detail.

 Software Development Antipattern

 The software development antipattern describes a situation encountered by the programmer when solving programming problems [4]. Software refactoring is the key goal of the software development antipattern. Software refactoring is a form of code modification mainly used to improve software structure in support of subsequent extension and long-term maintenance. In most cases, the goal of software refactoring is for code transformation without affecting the correctness negatively [3]. For system extension and maintenance to be considered efficient, it has to have a good software structure because software development is a chaotic activity that requires many phases. Implementing a good system structure is very important for efficient software maintenance.

 There are several types of software development antipatterns. They include the blob, continuous obsolescence, lava flow, ambiguous viewpoint, functional decomposition, poltergeists, boat anchor, golden hammer, dead end, and spaghetti code. The most important software development antipatterns will be discussed in detail.

The Blob

 The blob is also known as the God Class. The root cause of this antipattern is sloth and haste. The blob is found in designs with classes having dissimilar functionality where one class monopolizes the processing, and the encapsulation of data is primary done by another class. This type of software development antipattern are procedural rather than object-oriented architecture which separates the process from the data. The problem with this development antipattern is that most of the responsibilities are allocated to a single class

Symptoms and Consequences

• A single controller class with associated simple, data-object class
• Object-oriented design is absent
• Object-oriented architecture lacking a migrated legacy design needed for refactoring

Typical Cause

• Lack of an object-oriented architecture
• Lack of architecture enforcement
• Too limited intervention

Known Exceptions

The blob antipattern is acceptable when wrapping legacy systems.

Refactored Solution

 The solution to this type of antipattern is a form of refactoring by moving the behavior away from the blob and relocating the behavior to some of the encapsulated data objects in way that will make the blob less complex and the object more efficient.

Spaghetti Code

 The root cause of this antipattern is ignorance and sloth. The spaghetti antipattern is the most famous antipattern. It appears as a program or system that contains little software structure. The most susceptible language to this antipattern is nonobject-oriented language and very common among developers who are inexperience with the object-oriented concept. Spaghetti code makes the software structure lack clarity.

Symptoms and Consequences

• Relationships that exist among objects is minimal.
• Software quickly reaches a point of diminishing return.
• The pattern of use of object is very predictable and code is difficult to reuse.
• Benefits of object-orientation are lost.

Typical Cause

• No design prior to implementation.
• Less experience with object-oriented design technologies.
• Ineffective code reviews.
• Developers work in isolation frequently.

Known Exceptions

It is acceptable if the only implementation is spaghetti and interfaces are coherent.

Refactored Solution

 The refactored solution to this antipattern is frequent code refactoring. This can improve software structure, support software, and enable incremental development.

Cut and Paste Programming

 The cut and paste programming is also known as clipboard coding, software cloning, or software propagation. This is identified by the presence of similar code throughout the software project making maintenance a problem because of the code duplicates. The root cause of this antipattern is sloth. This antipattern is very common among inexperience developers who wants shortcut to programming making maintenance a nightmare.

Symptoms and Consequences

• Despite many fixes, the same software bug still reoccurs.
• Extended code reviews and inspection.
• Software defects are replicated through the system and this leads to excessive maintenance cost.
• Less effort for code reuse.

Typical Cause

• Lack of forward thinking among the development teams.
• There is lack of abstraction among developers.
• Development teams practicing no thinking outside the box.
• The intent behind a software module is not preserved along with the code.

Refactored Solution

 Black-box reuse reduce maintenance issues by having common source code, testing, and documentation.

Boat Anchor

 The boat anchor is a piece of software or hardware that does not in any way affect the current project. The boat anchor is usually acquired to compel time, and this makes it unclear why it needs to be included in a software project.

Symptoms and Consequences

• If the boat anchor is a hardware and does not meet the intended purpose, it will become useless.

Known Exceptions

It is acceptable if the primary aim is to get the code out of the door but there is a price to be paid for cut and pasting which would inherently increase maintenance cost.

Refactored Solution

 The refactored solution for boat anchor is making a rational decision that would be used as an objective selection process prior to the acquisition of boat anchor.

Software Architecture Antipattern

 The software architecture antipattern focuses on the system-level and enterprise-level structure of application and components [6]. Just as good software architecture is important for software extension and maintenance, same way good software architecture is a critical factor in the success of the system development because it provides a view of the whole system. The whole system architecture, which includes all aspect of the design, implementation, including the hardware and technology selection is referred to as software architecture. Some common software architecture antipatterns are autogenerated stovepipe, stovepipe enterprise, jumble, stovepipe system, cover your assets, vendor lock-in etc. The most important software architecture antipattern will be discussed in detail.

Stovepipe Enterprise

 The stovepipe enterprise antipattern is also known as island of automation. The root cause of this antipattern is haste, apathy, and narrow-mindedness. The stovepipe is a term commonly used to describe software systems with disjointed architecture. Enterprise involves multiple systems that are individually designed at different levels. System independency rather than commonality truncates coordination or interoperability between systems, prevents reuse, and drives up cost. Additionally, lack of commonality between software systems also causes reinvented system architecture and services lacks quality structure supporting adaptability. 

Symptoms and Consequences

• Business needs are not supported due to the inability to extend system.
• Subsystems between enterprise systems lacks software reuse.
• Changing business requirements may lead to excessive maintenance cost.
• Technology standard s are not correctly used.
• Incompatibility between enterprise systems in terms of terminology, approach, and technology.

Typical Cause

• Lack of reference model and system architecture.
• Lack of communication between system development.
• Technology standards being used lacks knowledge.

Known Exception

 It is unacceptable for new systems at an enterprise level.

Refactored Solution

 The refactored solution to stovepipe enterprise is coordination of technologies.

  Stovepipe System

 The stovepipe is also known as the legacy system, ad hoc integration. The root cause of this antipattern is haste, avarice, ignorance, and sloth which inherently affect the qualities of the internal structure of the system. The stovepipe system antipattern is the single-system analogy of stovepipe enterprise and is concerned with how the subsystems are coordinated within a single system compared to the stovepipe enterprise which is concerned with multiple systems [6].  The key problem in this antipattern is the lack of common abstraction in the subsystem while in stovepipe enterprise, the key problem is the common multisystem convection absence.

Symptoms and Consequences

• Even if system comply with most paper requirements, it still does not meet user expectations.
• Users must invent workarounds to cope with system limitation.
• Persistent difficulty in making changes to the system.
• Serious bugs may be introduced into the system as a result of system modification.

Typical Cause

• Architecture lacks vision.
• All interfaces are unique to each subsystem due to lack of abstraction.
• Not enough information or metadata to support system.
• Integrated subsystems lack the presence of common mechanism which makes it difficult to make modification to the architecture.

Known Exception

 It is acceptable for achieving a rapid solution for protype design.

Refactored Solution

 The refactored solution to stovepipe system antipattern is a component architecture that provides for flexible substitution of software modules [6].

Vendor Lock-in

 The vendor lock-in architecture antipattern is also known as product dependent architecture, bondage and submission, and connector conspiracy. The root cause of this antipattern is sloth, apathy, pride and ignorance. This occurs when there is a dependency on the vendor’s implementation making the software products adopt a product technology from them. Software changes and interoperability problems occur when upgrades are done. Continuous maintenance is required to keep the system running because any failure may result to a failure of the software project.

Symptoms and Consequences

• Application software maintenance cycle are driven by commercial product upgrades.
• Open systems standard varies significantly from the advertised product.
• Application updates may result to problem if the promised product features are delayed or never delivered.

Typical Cause

• In-depth product knowledge is required for efficient programming.
• Little to no technical approach provided for isolating application software from direct dependency upon the product.
•  No effective conformance process for the standard since product varies from the published open system standard.

Known Exception

 The vendor lock-in antipattern is acceptable when most of the code needed in an application is made up of a singles vendor’s code.

Refactored Solution

 Isolation layer is the refactored solution to vendor lock-in antipattern.  The isolation layer separates software packages and technology. An isolation layer can be used to provide software portability from underlying middleware and platform-specific interfaces [4].

Reinvent the wheel

 The reinvent the wheel antipattern is also known as design in vacuum and greenfield system. The root cause of this antipattern is pride and ignorance. Software reuse is different from design reuse. Software reuse involves the creation of a library of reusable components, the retrieval of those components, and the integration of the components with a system while design reuse involves architecture and software interfaces reuse in multiple application systems [3]. This antipattern occurs as a result of the lack of technology transfer between software projects which eventually leads to substantial reinvention.

Symptoms and Consequences

• Commercial software functions are replicated.
• Schedule and budget overruns as a result of poor management of risk and cost.
• Support for change management and interoperability is inadequate.
• Extended development life cycle involving failed and dead-end prototypes.

Typical Cause

• No communication and technology transfer between software development projects.
• When key architecture process such as architecture mining and domain engineering is absent.
• Lack of enterprise management of the computational viewpoint.

Known Exception

 This antipattern is only suitable for a research environment.

Refactored Solution

The refactored solution to reinvent the wheel is architecture mining which is used to quickly create a successful object-oriented architecture that are robust, product-independent, capable of being reused, and extensible.

Software Project Management Antipattern

 The software project management antipattern describe common problems and solutions due to the software systems [6]. This antipattern is one of the most important of all the antipatterns because can cause the death of the organization. The purpose of this antipattern is to build new awareness that enables a project manager to enhance success. Software project management antipattern describes how software projects are impaired by the people issues, processes, resources, and external relationships [6]. There are several project management antipattern and some of the important ones are Analysis paralysis, death by planning, fear of success, intellectual violence, corncob etc. all these will be discussed in detail.

Analysis Paralysis

 The analysis paralysis antipattern is also known as waterfall or process mismatch. The root cause of this antipattern is pride and narrow-mindedness. Primarily focusing on achieving perfection and completeness in the analysis phase rather than incremental development results in analysis paralysis. Analysis paralysis assumes the waterfall model that detailed analysis can successfully be completed prior to coding. When the analysis documents do not make sense to the domain expert is a key indicator of analysis paralysis.

Symptom and Consequences

• Personnel changes leads to multiple project restarts.
• In the analysis phase, design and implementation issues are continually reintroduced.
• Much of the analysis performed is speculative, hence no longer involves user interaction.

Typical Causes

• Goals are not well defined in the analysis phase.
• Planning or leadership lapses when moving past the analysis phase.
• More attention is focused on the analysis phase rather than considering all the phases the system development life cycle.

Known Exception

 There is no exception for analysis paralysis

Refactored Solution

 Incremental development has always been the key to the success of object-oriented development. Therefore, incremental development of all phases is the refactored solution to analysis paralysis in that way analysis phase will not only be the phase that will have a perfect completion, hence, the design, coding, testing, and the validation phase.

Death by Planning

 The death by planning is also known as glass case plan or detailitis plan.  The root cause of this antipattern is avarice, ignorance and haste. Many projects fail from over planning. Occurrence of cost tracking and staff utilization monitoring often result from death by planning. There exist two types of over planning and they are glass case plan which ceases once the project starts and the detailitis plan which continues until the project ceases to exist.

Symptom and Consequences

• Inability to plan at pragmatic level
• Focus is on cost rather than delivery
• Possibility of losing staff
• Project cancellation

Typical Causes

• No up to date plan for the project that shows the software components deliverable and their dates.
• Ignorance of basic project-management principle.
• Excessive planning without achievable goal.

Known Exception

 There is no exception for death by planning

Refactored Solution

 The refactored solution to death by planning would be to have a project plan that shows the primary deliverables.

Fear of Success

 The fear of success antipattern occurs when people worry too much about what kind of things could go wrong. Hence, people and project will be on a brink of success. One common example of this antipattern is insecurities about their professional competence. The fear of success makes it very easy for software project to fail. When insecurities about professional competence are discussed openly, this thought occupies the mind of so many of the project team members. At this point, irritational decisions could be made and actions that does not in any way beneficial to the progress of the project may be taken to address these concerns which most likely would result to project termination or cancellation.

Refactored Solution

 Fear of success could lead to team and project failure if not handle properly. Declaring success near the end of a project with a statement supporting the successful outcome is one important action that management can take. By declaring success can also help to reduce the fear of termination issues.

Intellectual Violence

 The intellectual violence antipattern is very common in the software industry where some project team members think that they know it all and use that to intimidate others. This antipattern occurs when someone who is very adept in theory, technology, or the buzzword uses this knowledge to intimidate and belittle in a meeting scenario.

Refactored Solution

 The refactored solution to this antipattern would be set up alternative organizational culture that would encourage mentoring and constant cross training of people. The mentoring culture is best aided through leadership by example and people are often encouraged to share their knowledge to promote the overall success of the organization through mentorship.

References

1. https://drive.google.com/open?id=1N25LwIsS8-aw8G-DuFp0pIAXkUt4M0In
2. https://en.wikipedia.org/wiki/Anti-pattern
3. https://drive.google.com/open?id=1JPzPWLKtnnYEXMkvp3BmqJ5MlvvQ1Mjm
4. https://drive.google.com/open?id=1Rsnri6DK6CcVNt5kJ6Qwt54KSdKRhiT_
5. https://drive.google.com/open?id=1T3hDyOa19x36jz6EHKLpN8hiFjYuIm9P
6. https://sourcemaking.com/antipatterns