Anti-PatternsRefactoring Software, Architectures and Projects in Crisis

Siddhesh Bhobe8-Aug-2002

Menu Definition Motivation for AntiPatterns Software Development AntiPatternsIn Part II: Software Architecture AntiPatterns In Part III: Software Project Management

AntiPatterns

Pattern… Arrangement of repeated parts Design or shape to direct the

cutting of cloth Model or specimen

But a pattern can also be one of behavior!

AntiPattern… Tells you what to avoid Identification of what to avoid is a

critical factor in successful software development

AntiPatterns rampant in Software Development Architecture Management Behavior

Occur as a result of… Manager or developer not knowing

better Insufficient knowledge or

experience in solving a particular type of problem

Applying a perfectly good pattern in wrong context

“An AntiPattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences”

Questions How can I recognize the most

common software design mistakes? What can we do to fix bad software? How can we get our design process

on track? How do I know when I am being

misled by a vendor?

More Questions Is the latest standard or

technology breakthrough going to solve my problems?

Is our project headed for disaster? What are the “gotchas” of software

reuse?

Software Development AntiPatterns

AP: The Blob

“This is the class that is really the heart of our architecture”

Symptoms and Consequences Procedural-style design One object with lion’s share of

responsibility Others hold data or execute simple

processes Lack of cohesiveness Too complex for reuse and testing

Typical Causes Lack of architecture skills Prototypes developing into

production systems Defining system architecture as

part of requirements analysis

Known Exceptions Wrapping legacy systems Just make the system accessible

Solution Identify functionalities according to

“contracts” Find “natural homes” for these

collections of functionalities Remove redundant associations Top Down Approach: Migrate some

functionalities to the data classes

AP: Lava Flow

“Oh that! Well Ray and Emily wrote that routine back when Jim was trying a workaround for Irene’s input processing code. I don’t think it’s used anywhere now, but I am not sure. It isn’t really documented clearly, so just leave it alone”

Symptoms and Consequences Frequent unjustifiable variables

and code fragments Loose, “evolving” architecture Dead code or commented out

blocks

Typical Causes R&D code placed into production Uncontrolled distribution of

unfinished code Single developer written code Lack of configuration management Transient development teams Hasty changes on the fly

Known Exceptions Small-scale prototypes in R&D

environments Deliver rapidly and results not

required to be sustainable

Solution Ensure that sound architecture

precedes code development Configuration Management Curing existing problem is often

very painful

AP: Functional Decomposition

“This is our ‘main’ routine, here in the class called LISTENER”

Symptoms and Consequences Resembles procedural language in

class structure Classes with names like

“Calculate_Interest” is a sure indication

Classes with all private variables No inheritance Can result in incredibly complex code

Typical Causes Output of experienced non-object

oriented programmers who design an implement an OO application

Known Exceptions Fine when OO solution is not

required, and only required to give an OO interface to the implementation code

Solution Define analysis model to explain the

critical features of the system Formulate design model that

incorporates essential pieces Combine several classes that satisfy

a single design objective (Helper classes).

Rewrite classes with no state as function

AP: Poltergeists: Restless Ghosts

“I am not really sure what this class does, but it sure is important!”

Symptoms and Consequences Temporary, short duration objects Redundant navigation paths Transient associations Single-operation classes that “seed”

other classes Classes with “control-like” operation

names like “start_process_alpha”

Typical Causes Bad architecture or design Wrong tool for the job Architectural commitments during

requirements analysis

Known Exceptions No exceptions

Solution Remove these classes from the

hierarchy Add functionality in the related

classes they invoked

AP: Boat Anchor Piece of hardware or software that

serves no useful purpose on the current project

Typical Causes Policy or programmatic

relationship Starting assumption or constraint

in a project Commitment to product without

technical evaluation

Solution Keep technical backups during

evaluation phase Prototype with evaluation licenses Rational decision making prior to

acquisition

AP: Golden Hammer

“Maybe we shouldn’t have used Excel macros for this job after all”

Symptoms and Consequences Identical tools and products used for

wide array of conceptually diverse requirements

Inferior performance and scalability Developers debate requirements

with analysts and end users Existing products dictate design and

architecture

Typical Causes Familiar technology or concept

applied obsessively to many problems

Large investments made in training in a particular technology or product

Reliance on proprietary features

Known Exceptions If the product that defines the

constraint is the intended strategic solution for long term

Product is part of a vendor suite that provides for most of the software needs.

Solution Commitment to alternative

technologies and approaches Hiring people with diverse

backgrounds and experiences Exposure of developers to

technical developments

AP: Dead End Modified reusable component no

longer supported or maintained by the supplier

Shifts burden to the developer and maintainers

Upgrades cannot be easily integrated Support problems get blamed on

modifications

Known Exceptions Testbeds that support basic

research such as throwaway code Significant benefits through

customization

Solution Avoid COTS Customization and

modifications to reusable software Use mainstream platforms and

upgrade in sync with vendor Use isolation layers

AP: Spaghetti Code

“It’s easier to rewrite this code than attempt to modify it”

Symptoms and Consequences Very low reuse value Flow dictated by object

implementation, not by clients Minimal relationships between

objects Difficult to maintain and extend

Typical Causes Inexperience Ineffective code reviews No design prior to implementation Developers working in isolation

Known Exceptions Reasonably acceptable if

interfaces are coherent Lifetime of the code is short Product developed to obtain

domain knowledge for designing products with an improved architecture later on

Solution Code cleanup Term doesn’t appeal to managers,

so call it “software investment” Code cleanup should follow each

addition of feature Performance improvement is also

part of code cleanup

Examples of code cleanup Write accessor functions for use in

refactored code Convert code segments into

functions for reuse Reorder function arguments for

consistency Remove inaccessible or dead code Rename classes, functions, variables

AP: Input Kludge “End users can break new

programs within moments of touching the keyboard”

Use of ad hoc algorithms for handling program input

Solution: Use production-quality input algorithms like lexical analysis and parsing software

AP: Cut-and-Paste Programming

“Man, you guys work fast. Over 400,000 lines of code in three weeks is outstanding progress!”

“Hey, I thought you fixed that bug already, so why is it doing this again?”

Symptoms and Consequences Similar segments of code all over

the code base Duplication of testing, review, bug

fixing efforts

May have positive short-term consequences increased like line count

Typical Causes Degenerate form of software reuse:

Reusing source code Inexperienced programmers

following examples of other senior programmers

Taking working examples and modifying them

Organization rewards development speed, not reuse and overall design

Known Exceptions When the sole aim is to get the

code out of the door as quickly as possible

However, price paid is one of increased maintenance

Solution Black box reuse

In Part II and III… Software Architecture AntiPatterns Software Project Management

AntiPatterns

References AntiPatterns: William Brown,

Raphael Malveau et al (PSPL Library S-76)

http://www.antipatterns.com/thebook.htm

Similar presentation at http://www.mitre.org/support/swee/html/67_mccormick

Thank You!