Lecture 14: Antipattern

Question 1

Pattern Definition

Answer 1

A pattern has two parts: A Problem and a Solution.

• The problem class is elaborated in terms of a Context and a set of Forces
• The solution resolves these Forces with Benefits and Consequences
• To be considered as a pattern, the solution must be applicable to more than one specific problem

Solutions usually generate Follow-on Problems

• Follow-on problems can again be elaborated in terms of Context and Forces which may lead to the applicability of other patterns.

Question 2

Patterns can become Antipatterns

Answer 2

Patterns can evolve into Antipatterns when change occurs

• Examples of changes:
  
  • Change of requirements (functional, nonfunctional and pseudo requirements)
    
    • Moving from a desktop-system to a smart phone
  • Change of project parameters
    
    • Increase of budget, extending the project finish time, people leaving the project
  • Change of methodology
    
    • Moving from functional decomposition to object-orientation
    • Moving from a defined process to an agile process
• In those cases the solution proposed by the pattern becomes a problematic solution.

Question 3

Informal Antipattern Definitions

Answer 3

• Antipattern identify and categorize the common mistakes in software practice
• „An Antipattern is something that looks like a good idea, but which backfires badly when applied.“ (Jim Coplien)
• Synonyms for Antipattern
  
  • Description of a bad practice
  • Description of a bad idea or pitfall
  • Description of a typical project management mistake
  • Description of a typical design error
  • Description of the bad use of an activity.

Question 4

Antipattern

Answer 4

Definition

• An Antipattern consists of a problem and two solutions:
  
  • The Problematic Solution describes a commonly occurring solution that generates overwhelming negative consequences
  • The Refactored Solution describes how the problematic solution can be reengineered to avoid these negative consequences and lead to benefits again
    • The Refactored Solution often leads to Follow-On Problems.

Question 5

Applicability of Patterns and Antipatterns

Answer 5

• Patterns are good for problems which have no solution yet
  
  • Innovation projects (Green field engineering projects)
• Patterns emphasize the use of proven good design principles
  
  • information hiding, high coherence, low coupling, …
  • “Thou shall not …”
• Antipatterns are good for emphasizing the recognition of mistakes in existing systems, software projects and software processes
  Examples:
  
  • Bad design
  • Too much time spent in analysis
  • Constantly missing deadlines
    
    • Typical excuse: “I knew about this design shortcut, but I had no choice because of {budget, deadline, missing resources,…}….

Question 6

Changing bad solutions into better ones

Answer 6

• When a pattern becomes an antipattern, it is useful to have an approach to change the problematic (bad) solution into a better one
• Incremental Reengineering (Refactoring):
  
  • The process of incrementally changing the bad structure of a system, project or organization into a better structure with the use of antipatterns

Question 7

Why Antipatterns?

Answer 7

“The study of Antipatterns is an important research activity.

The presence of good patterns in a successful system is not enough. You also must show that those patterns are absent in unsuccessful systems.

Likewise, it is useful to show the presence of certain patterns in unsuccessful systems, and their absence in successful systems.”

Bruegge’s Corollary: It is also useful to show the presence of certain patterns in unsuccessful projects, and their absence in successful projects.

Question 8

Typical Mistakes in Software Development

Answer 8

• What do you have to do to kill a project?
  
  • Show the same demo twice to the same audience
  • Focus on technologies, not on problems and scenarios
  • Don’t maintain consistency between releases
  • Isolate team efforts from other teams within an organization
  • Rewrite existing clients, servers and applications
  • Change the purpose of the system so that the models describe the wrong objects

Question 9

Root Causes for Antipatterns

Answer 9

• Most common mistakes in software project management and development:
  
  • 1. Insufficient communication with the client
  • 2. Unfulfilled requirements
  • 3. Insufficient testing
  • 4. Cost overruns and schedule slips
• Reason for these mistakes: “The 7 deadly sins”
  
  • Pride, greed, lust, envy, gluttony, wrath and sloth
    
    • SALIGIA (Latin): superbia, avaritia, luxuria, invidia, gula, ira, acedia
  • Now a popular analogy used to identify ineffective practices
    
    • Haste, Pride, Apathy, Sloth, Ignorance, Avarice, Narrow-Mindedness.

Question 10

The Seven Deadly Sins in Software Practice

Answer 10

• Haste
  
  • Solutions based on hasty decisions (“time is most important”) lead to compromises in software quality
• Pride (Hubris)
  
  • Not invented here (NIH): Not willing to adopt anything from the outside
• Apathy
  
  • Not caring about a problem, followed by unwillingness to attempt a solution
• Sloth
  
  • Making poor decisions based on “easy” answers
• Ignorance
  • Failure to seek understanding
• Avarice (Excessive Complexity)
  
  • No use of abstractions, excessive modeling of details
• Narrow-Mindedness
  
  • The refusal to use solutions that are widely known (“Why reuse? I only have to solve one problem”).

Question 11

Anti Pattern Taxonomy

Answer 11

• Development Antipatterns
  
  • Focus on the viewpoint of the software developer
  • Issues: Software refactoring, modification of source code to improve the software structure with respect to long-term maintainability
• Architecture Antipatterns
  
  • Focus on the viewpoint of the software architect
  • Issues: Partitioning of subsystems and components, platform independent definition of interfaces, and connectivity of components
• Management Antipatterns
  
  • Focus on the viewpoint of the software project manager
  • Issues: Software project organization, software project management, software process model, human communication, rationale management and resolution of issues.

Question 12

Analysis Paralysis Antipattern

Answer 12

• General Form
  
  • Goal to achieve perfection and completeness of the analysis phase
  • Generation of very detailed models
  • Assumption, that everything about a problem can be known a priori
  • Detailed analysis can be successfully completed prior to coding
  • Analysis model will not be extended nor revisited during development
• Symptoms And Consequences
  
  • Cost of analysis exceeds expectation without a predictable end point
  • Analysis documents no longer make sense to the domain experts
• Typical Causes
  
  • Management assumes a waterfall progression of phases.

Question 13

Plan-Driven Software Development

Answer 13

• Linear, phase oriented process
  
  • Start –> Analyze – > Design –> Implement
    
    • Main goal to minimize risk through careful upfront planning
    • Equates phrases with activities
    • No iterations, just one pass

Question 14

Best Known model of Plan-Driven Software Development: The Waterfall Model

Answer 14

• You start with activity 1 (requirements elicitation)
• When you are finished with requirements elicitation, you move to activity 2 (analysis)
• When you are finished with analysis, you proceed with design
• When you are finished with design, you proceed with implementation
• When you are finished with implementation, you proceed with testing
• When you are done with testing, your system is successfully built.

Question 15

Viral Marketing: A new Pattern

Answer 15

• Bruce Kammerl and Microsoft used Viral Marketing
  
  • Also called Content Marketing, Linkbait, Virus Marketing
  • Mostly used in online marketing
  • Goal: Maximum reach out for a new product

Question 16

Analysis Paralysis Antipattern Refactored solution

Answer 16

• Refactored Solution
  
  • Iterative Development
  • Incremental development assumes that details of the problem and its solution will be learned in the course of the development process
  • Vertical prototyping
  • Scenario based design
  • Sprint based development

Question 17

Functional Decomposition Antipattern

Answer 17

• Also Known As No OO
• General Form
  
  • Every thing is a function, lots of files called misc, util, util1, aux1, aux2…
• Unbalanced Forces
  
  • Management of complexity, change management is difficult
• Symptoms And Consequences
  
  • Maintainer must understand the whole system to make a single change
  • Code is hard to understand
  • Code is complex, high coupling between code sections in different files
  • User interface is often awkward and non-intuitive
• Typical Causes
  
  • Programmers have been trained only in an imperative language
  • Designers trained with a functional decomposition method (DeMarco)
• Refactored Solution Name
  
  • Object-oriented analysis, Object-oriented reengineering.

Question 18

Functional Decomposition: Symptoms and Consequences

Answer 18

• The functionality is spread all over the system
• Maintainer must understand the whole system to make a single change to the system
• Consequence:
  
  • Source code is hard to understand
  • Source code is complex and impossible to maintain
  • User interface is often awkward and non-intuitive

Question 19

Corncob Antipattern

Answer 19

Background

• Corncobs are difficult people
• Corncobs usually create additional stress in what may be an already overstressed environment especially in the software projects
• Reasons:
  
  • Individual personality
  • personal motivations for recognition or monetary incentives
  • Rigorous schedules and budget pressure.

Question 20

Corncob Antipattern: Anecdotal Evidence

Answer 20

• “Why is Bill so difficult to work with?”
• „Management always listens to whomever shouts longest and loudest“
• “I am the manager, I have made a decision that you will follow.

Question 21

Seven Types of Difficult People

Answer 21

• Hostile Aggressives
• Sherman Tanks
• Snipers
• Exploders
• Indecisives
• Whiners
• Negativists
• Clams
• Bulldozers
• Superagreeables

Question 22

Corncob Antipattern

Answer 22

• Also Known as:
  
  • Corporate Shark, Loose Cannon, Third-World Information Systems Troubles (TWIT)
• Root Causes:
  
  • Pride, Avarice, Ignorance, Narrow-Mindedness
• General Form:
  
  • A difficult person (the Corncob) causes problems through destructive behaviors for a software development team
  • Corncobs focus much more on politics than technology. They are usually experts at manipulating politics.

Question 23

Corncob: Symptoms And Consequences

Answer 23

• A project is unable to make progress because someone disagrees with key objectives or essential processes and continually tries to change them
• Political forces create an environment where it’s difficult to keep technical discussions on track
• Political forces result in frequent changes to the scope or requirements of the system

Question 24

Corncob: Typical Causes and Known Exceptions

Answer 24

• The Corncob has a hidden agenda, which conflicts with the team’s goals
• There is a fundamental disagreement between the corncob and the team members
• Management has inappropriately allocated roles to staff, who abuse them for their own ends
• Known Exceptions
• is acceptable when a company or product development manager is willing to live with the actions of the Corncob
• In projects that involve multiple organizations, it’s sometimes useful to have a designated Corncob, whose role is to defend an existing architecture from inappropriate changes

Question 25

Corncob: Refactored Solution

Answer 25

• Transfer the responsibility. Turn the responsibility for planning and resolution over to the person who raises the concerns
• Question the question. When the Corncob uses ambiguous or “loaded” words or phrases, ask him or her to clarify their meaning
• Corrective interview. Management meets individually with the person causing the problems, and explains the impact of his or her behavior
• Friendly outplacement. Recommend a Corncob to employment headhunters to help him or her to exit gracefully
• Corncob support group. If there are several Corncobs in an organization, management can transfer them into the same group.

Question 26

Death by Planning: Anecdotal Evidence

Answer 26

• “We can’t get started until we have a complete program plan.”
• “The plan is the only thing that will ensure our success.”
• “As long as we follow the plan and don’t diverge from it, we will be successful.”
• “We have a plan, we just need to follow it!”

Question 27

Death by Planning

Answer 27

General Form

• Many projects fail from either over-planning or underplanning.
• Glass Case Plan: Gives the management a ‘comfortable view’ of delivery, often before the project starts
• Detailitis Plan: Over-planning in projects, resulting in delays, staff attrition, and project failure.

Question 28

Death by Planning: Glass Case plan

Answer 28

• Detailed plan is produced at the start of a project
• Management assumes as there is a plan, delivery will follow automatically, exactly as its planned
• The plan is neither tracked against, nor updated, but referred to as if it is an accurate, current view of the project.

Question 29

Death by Planning: Detailitis Plan

Answer 29

• Effective delivery is assumed to be achieved by a high degree of control via continuous planning
• Frequently evolves into a hierarchical sequence of plans, often with unnecessary level of detail (usually visualized with a PERT chart, or a GANTT chart)
• However, to produce and update the plan requires effort from those who should be implementing it

Question 30

Death by Planning:
Symptoms And Consequences

Answer 30

Glass Case Plan

• Primary symptom, lack of an up-to-date project plan
• Secondary symptom, as no up-to-date plan, increase in differences between management expectations and reality (an extension of primary symptom)
• Consequences grow incrementally, with the options of;
  
  • Lack of status quo of the project status
  • cost overrun
  • Attrition
  • Failure to deliver a critical deliverable (final consequence)

Question 31

Death by Planning:
Symptoms And Consequences

Answer 31

Detailitis Plan

• Symptom: A lot of time is spent on planning, capturing progress, and replanning
  
  • Often more time than on delivering the software
• Consequences:
  
  • Endless planning and replanning causes further planning and replanning
  • Objective shifts from delivering software to delivering plans
  • Delays in software delivery lead to project failure.

Question 32

Death by Planning: Typical Causes

Answer 32

• Root Causes
  
  • Avarice, Ignorance, Haste
• Causes for the Glass Case Plan
  
  • A tool used for contract acquisition with no intended follow-through
  • Overambitious initial planning to attempt to enforce absolute control of project
  • Ignorance of basic project-management principles
  • Lack of a pragmatic approach to planning, scheduling, and capture of progress
• Causes for the Detailitis Plan
  
  • Overambitious continuous planning to attempt to enforce absolute control of the project
  • Planning as the primary project objective
  • Ignorance of change
  • Compliance forced by customer.
• Known Exceptions
  • Software development projects can succeed despite poor planning practices
  • The existence of a “project champion” within the management level can prove beneficial even in the context of bad planning
• Refactored Solution
  
  • Create schedule of related development tasks defined by a software development lifecycle model (use Gantt Chart)
  • Estimate the tasks in terms of effort and elapsed time
  • Capture the progress of tasks for an elapsed time period (use Burn Down Chart)
  • Evaluate captured against the project plan
  • Update the captured against the project plan.

Question 33

Mushroom Management Antipattern

Answer 33

• Background:
  
  • Requirements change frequently
  • Bad understanding of the requirements leads to the poor design decisions
    
    • Developers must make assumptions, which may lead to pseudo-analysis
    • Pseudo-Analysis: Analysis that takes place without end-user participation.

Question 34

Mushroom Management Antipattern

Answer 34

• Also known as:
  
  • Pseudo-analysis, blind development
• Unbalanced Forces:
  
  • Management policy isolates the developers from the system’s end users
  • Management assumes that the requirements are stable and well understood by developers.

Question 35

Mushroom Management: Anecdotal Evidence

Answer 35

“I keep my developers in the dark about the end user, because otherwise the end user will constantly bother them with questions”

Question 36

Mushroom Antipattern: Refactored solution

Answer 36

• Introduce incremental and iterative development
  
  • Incremental and/or iterative development process based upon prototyping and user feedback
  • Every project increment includes extensions to the user-interface functionality
  • Incremental development reduces the risk of the project not being accepted
• Include a domain expert in the development team
  
  • Follow-On Problem: The domain expert represents only one opinion from the domain community
• Include a user in the development process
  
  • Follow-On Problem: In innovative projects the end user may not exist

Question 37

Summary

Answer 37

• Functional Decomposition (Developer, Architecture, Manager)
  
  • Design and implementation style from developers, who got their initial training in structure analysis methods and imperative languages, with no or little experience in OO methods and OO languages
• Analysis Paralysis (Management Antipattern)
  
  • Spending excessive time in requirements elicitation and analysis
• Corncob (Management Antipattern)
• Death by Planning (Management Antipattern)
  
  • lack of an up-to-date project plan
• Mushroom (Management Antipattern)
  
  • Bad understanding of requirements, Management isolates developers
• from the system’s end users.