By Thomas Hutton




Definition
AntiPattern Template
Benefits of Identifying AntiPatterns
Benefits of Understanding AntiPatterns

“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)


“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)

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


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

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.”


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.

Why would one produce such a program?
◦
◦
◦
◦
Too little time.
General laziness.
Technical Inability
Changes to Requirements

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-anddirty hacks and kludges that absolutely will not
stand the test of time.” (Borenstein, 118)

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.





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








AntiPattern Name
Also Known As
Most Applicable Scale
Refactored Solution Name
Refactored Solution Type
Root Causes
Unbalanced Forces
Anecdotal Evidence






Background
General Form
Symptoms and Consequences
Typical Causes
Known Exceptions
Variations

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.

Refactored Solution Type
◦
◦
◦
◦

Software
Technology
Process
Role
Unbalanced Forces
◦ Management of “primal forces” – organizational
pressures that occur







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




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.”

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?

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

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.




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



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)

From our example: “I know how we can fix
this problem! We’ll implement a standard.”

“Standards are worthless.”

“Just stick to the standards!”



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







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

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

Projects that do no need standards
◦ Very small, quick, and have little complexity
◦ Be wary of falling into the One-Shot Deal
AntiPattern



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

Stand alone

No hidden causes

Related to the people, technology and/or
process
WebSphere MQ Monitoring



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.

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.

Trust your intuition!

Talk to coworkers about your concerns.
◦ They have just as much at stake as you do.

Read a book.

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
Increased Understanding of Best Practices!

Borenstein, Nathaniel S. Programming as If

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.
People Mattered: Friendly Programs, Software
Engineering, and Other Noble Delusions.

Chemuturi, Murali, and Thomas M. Cagley.

Lauderdale, FL: J. Ross Pub., 2010. Print.
Dudney, Bill. J2EE Antipatterns. Indianapolis,
IN: Wiley Pub., 2003. Print.
Mastering Software Project Management: Best
Practices, Tools and Techniques. Ft.
◦ Found online via school library at
http://pltlib.wisconsin.edu/vwebv/holdingsInfo?sea
rchId=797&recCount=25&recPointer=0&bibId=242
218&searchType=7