AntiPatternsBy Thomas Hutton

Definition AntiPattern Template Benefits of Identifying AntiPatterns Benefits of Understanding AntiPatterns

Overview

“Software engineering consists of all the technical activities that are performed to build the project deliverable (the “just build it” activities). Software engineering deals with construction the components, integrating them, verifying them, validating them, and finally combining all of the components into a product and convincing the customer to accept delivery of it.” (Chemuturi, 19)

Definition

“Mechanism to describe a commonly occurring solution to a software development need that generates significantly negative consequences.” (Brown, XXVII)

“An AntiPattern is a repeated application of code or design that leads to a bad outcome.” (Dudney, XIX)

Definition

A process that works for one team or project may not work for another.◦ Not necessarily an AntiPattern

Not limited to any single area.◦ Project Management◦ Analysis/Design◦ Code

A Matter of Perspective

Software Engineering processes are based off best practices compiled from experiences.

AntiPatterns are a key building blocks for these processes – they represent failed processes.

Learning from mistakes

Yin Yang

An programming assignment is due in two days. Due to your class load, you do not have the considerable amount of time to correctly produce a proper solution. As a result, you think to yourself “I just need to hand something in. At least I will get some credit.”

Example

Also known as: The Quick’n’Dirty

Understanding of the project is that the code must be produced quickly and will not be maintained later.

One-Shot Deal

Why would one produce such a program?

◦ Too little time.◦ General laziness.◦ Technical Inability◦ Changes to Requirements

Root Cause

Prototypes◦ Built with the idea that the code may be

scrapped, but will provide data on the direction of the project.

◦ “This implies, practically speaking, that programmers must learn to disregard their notions of “professional pride” and produce what they typically thought of as amateurish code, quick-and-dirty hacks and kludges that absolutely will not stand the test of time.” (Borenstein, 118)

Common Forms

The Tool◦ Usually single developers given a mission to build

a program to quickly complete a simple task.

The Retrofit◦ Demand for a new architecture while functionality

is untouched.

Common Forms

Leads to programs that cannot be maintained

Generally programs are of poor quality Programs are unlikely produce proper

output in test scenario Lack of documentation Inefficient or dead code

Symptoms

AntiPattern Name Also Known As Most Applicable Scale Refactored Solution Name Refactored Solution Type Root Causes Unbalanced Forces Anecdotal Evidence

AntiPattern Template

Background General Form Symptoms and Consequences Typical Causes Known Exceptions Variations

Detailed Template

Most Frequent Scale◦ Global: Design issues across all systems.◦ Enterprise: Coordination/communication across

an organization◦ System: Coordination/communication across

applications.◦ Application: Individual application.◦ Framework: Macro-level.◦ Micro-Architecture: Repeated use of solutions.◦ Object: Especially reusable objects.

Template - Details

Refactored Solution Type◦ Software◦ Technology◦ Process◦ Role

Unbalanced Forces◦ Management of “primal forces” – organizational

pressures that occur

Template - Details

Name: One-Shot Deal AKA: Quick’n’Dirty Scale: Enterprise Solution Name: Aim Before You Shoot Solution Type: Process Root Causes: Sloth, Haste, or Ignorance Unbalanced Forces: Management of IT

Resources

Apply the Template

From our example: “I just need to hand something in. At least I will get some credit.”

“We don’t need documentation.” “This isn’t a major release, we just need

something now.” “If we don’t get this done now, we won’t

ever get it done.”

Anecdotal Evidence

Aim Before You Shoot◦ Think about the implications of creating software

without documentation.◦ Ask if there is any chance this program will need

to be maintained.◦ Is anyone paying for this software?◦ How long is the software expected to be used?◦ How difficult is the software to create?

Solution

Prototypes◦ Managed expectations can lead to a prototypes

achieving their goal: to provide an example. Consider developing prototypes in a different

language. Automated Source Code Control Formal Defect Tracking Standards for Documentation/Testing

Exceptions

As a project manager, you are worried about the integrity and quality of code your developers are producing. So far, the code seems to fit into the design scheme and passes test cases, but you question the maintainability of the code. Therefore, you tell all of your developers to implement a new standard.

Another Example

Also Known As: The Necessary Evil Generally a problem with process Can be caused by pride or ignorance Often managers fail to understand the

complexity of new standards, reason to have standards at all

The Standards

Developers outright refuse to implement the new standards

Schedule is not changed to reflect the time and effort necessary to implement a standard

“Organizations pay lip service to quality standards or guidelines or… they implement the standards/guidelines poorly.” (Chemuturi, 213)

Problems

From our example: “I know how we can fix this problem! We’ll implement a standard.”

“Standards are worthless.”

“Just stick to the standards!”

Anecdotal Evidence

Additional work created by implementing a new and/or complex standard

Organization does not value standards and/or is not committed to implementing them

Selected standard is overly complex

Root Causes

Name: The Standards AKA: The Necessary Evil Scale: System Solution Name: Back to Zero Solution Type: Process Root Causes: Ignorance, Sloth, Apathy,

Narrow-Mindedness, or Pride Unbalanced Forces: Management of

Complexity

Apply the Template

Return to Zero◦ Look at the what is necessary to uphold your

expectations for quality

◦ Match the expectation to the standard

◦ Look for standards that support maintenance but are flexible

Refactored Solution

Projects that do no need standards

◦ Very small, quick, and have little complexity

◦ Be wary of falling into the One-Shot Deal AntiPattern

Exceptions

AntiPatterns can occur in sequence, meaning that one problem often leads to another.

Solving the first quickly may solve the subsequent AntiPatterns.

Generally due to lack of control

Interacting AntiPatterns

Stand alone

No hidden causes

Related to the people, technology and/or process

Isolated AntiPatterns

WebSphere MQ Monitoring

Personal Experience

Avoid or reduce the effects of the AntiPattern!

The sooner you identify a potential problem, the more likely you are to find a solution.

Remember failures – those experiences will help you succeed in the future.

Benefits to Identifying AntiPatterns

Chronicle problems that occur and the solution attempted.◦ Reuse or refine good solutions◦ Abandon bad solutions◦ Ask yourself “Why did this solution work or fail?”◦ The goal is to be consciously aware of the

problem, what caused it to occur and how to solve it.

How to Identify AntiPatterns

Trust your intuition!

Talk to coworkers about your concerns.◦ They have just as much at stake as you do.

Read a book.

How to Identify AntiPatterns

Aligned with the goals of software engineering◦ On time delivery◦ Cost within budget◦ Customers happy with delivered software

Avoidance of AntiPatterns◦ Prior knowledge is key

Benefits to Understanding AntiPatterns

Increased Understanding of Best Practices!

Benefits to Understanding AntiPatterns

Borenstein, Nathaniel S. Programming as If People Mattered: Friendly Programs, Software Engineering, and Other Noble Delusions. Princeton, NJ: Princeton UP, 1991. Print.

Brown, William J., Hays W. McCormick, and Scott W. Thomas. AntiPatterns in Project Management. New York: Wiley, 2000. Print.

Sources

Chemuturi, Murali, and Thomas M. Cagley. Mastering Software Project Management: Best Practices, Tools and Techniques. Ft. Lauderdale, FL: J. Ross Pub., 2010. Print.

Dudney, Bill. J2EE Antipatterns. Indianapolis, IN: Wiley Pub., 2003. Print. ◦ Found online via school library at

http://pltlib.wisconsin.edu/vwebv/holdingsInfo?searchId=797&recCount=25&recPointer=0&bibId=242218&searchType=7

Sources