Anti-PatternsRefactoring Software, Architectures and Projects in Crisis: Part 2

Siddhesh Bhobe

Last Week Definition Motivation for AntiPatterns Software Development

AntiPatterns

In Part II… Recap Software Architecture AntiPatterns In Part III: Software Project Management

AntiPatterns

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

Software Development AntiPatterns Blob Lava Flow Functional

Decomposition Poltergeists Boat Anchor

Deadend Spaghetti Code Input Kludge Cut-and-Paste

Programming Golden Hammer

Software Architecture AntiPatterns

AP: StovePipe Enterprise

“Can I have my own island (of automation)?”

“We’re unique!”

Stovepipe… Used to describe software systems

with ad hoc architectures Stovepipes need lot of

maintenance Repaired with whatever is at hand;

hodgepodge of ad hoc repairs

Symptoms and Consequences Incompatible technology,

terminology and approaches within the enterprise

Inability to extend Lack of reuse and interoperability Excessive maintenance costs

Typical Causes Lack of enterprise technology strategy Lack of incentive to cooperate:

competing business areas & executives

Lack of communication Lack of knowledge of technology

standards being used Absence of horizontal interfaces

Known Exceptions Takeovers and Mergers Wrapping some systems can be a

temporary solution

Solution: Define Models Requirements

Model Open Systems

Reference Model Technology Profile Operating

Environment System

Requirements Model

Specifications Model Enterprise

Architectures Computational

Facilities Interoperability Development

Profile

Open Systems Reference Model High Level Architecture List of target standards for system

development projects

IEEE POSIX 1003.0 standard

Technology Profile Define short-term standards plan Reference model is flexible;

Technology profiles mandate standards

US-DOD Joint technical Architecture

Operating Environment Defines product releases and

installation conventions Influence adoption of

recommended environments Variations should be supported

locally at extra cost

System Requirements Profile Summary of key requirements for

a family of related systems Scopes out the system capabilities Leads to enterprise wide planning

Enterprise Architecture Set of diagrams and tables that

define a system or family of systems

Consider views of end users, developers, system operators and technical specialists

Computational Facilities Architecture Identifies key points of

interoperability APIs and data objects Defines roadmap of priorities and

schedules for the facilities

Interoperability Specification Technical details of a

computational facility APIs in IDL and common data

object definitions Created using architecture mining

Development Profile Implementation plans and

developer agreements Assure interoperability and

successful integration Specifies local extensions to APIs

and conventions

AP: Stovepipe System

“The software project is way over budget; it has slipped it’s schedule repeatedly; my users still don’t get the required features; and I can’t modify the system!”

Symptoms and Consequences Single-system analogy of StovePipe

Enterprise Large semantic gap between

architecture and implementation Requirement changes are costly to

implement Maintenance is surprisingly expensive Complies with paper requirements, but

does not meet user expectations

Typical Causes Absence of common integration

mechanism Lack of abstraction Insufficient metadata makes it

difficult to extend and configure Lack of architectural vision

Known Exceptions R&D, Prototypes and Mockups Choice to use a vendor’s product

and not reinvent the wheel can also lead to this.

Solution Component architecture providing

flexible substitution of modules Abstractions and reduces

interfaces Use of metadata Decouple clients from services

AP: Vendor Lock-In

“When I try to read the new data files into the older version of the application, it crashes my system”

“Our architecture is… What’s the name of our database again?”

Symptoms and Consequences Commercial product upgrades

drive the application software maintenance cycle

Product varies significantly from advertised open systems standard

If upgrade is missed, repurchase and reintegration is necessary

Typical Causes Product differs from standards because

there is no conformance process Product selected based on marketing,

and not on detailed technical inspection Application software not isolated from

the vendor product Product more complex than required;

results in complexity of the application

Known Exceptions When the single vendor provides

most of the required functionality

Solution Isolate application from low level

infrastructure

AP: Wolf Ticket Claims conformance to standards

that have no enforceable meaning Proprietary interfaces

Wolf Tickets: Illegal/invalid tickets to rock concerts

AP: Architecture by Implication

“We’ve done systems like this before”

“There is no risk. We know what we are doing”

Symptoms and Consequences Lack of planning and specification of

architecture for software, hardware, communications, persistence, security, systems management

Hidden risks Unacceptable levels of performance,

usability, requirements acceptance

Typical Causes No risk management Overconfidence of managers,

architects and/or developers Reliance on previous experience

which may differ in critical areas Gaps in system engineering

Known Exceptions Repeated solution, with minor

difference like installation scripts Exploratory projects

Solution Organized approach to systems

architecture definition Goal-Question Architecture

4 + 1 Model View: Rational Rose (Logical, Use-case, process, implementation and deployment views)

AP: Warm Bodies Also known as Body Shop, Mythical

Man-Month Large projects with huge teams Adding more staff to ongoing software

project does not help! (Mythical Man-Month, 1979)

Small, compact teams make more sense

Recommended: 4 people, 4 months

AP: Design by Committee

“A camel is a horse designed by a committee”

“Too many cooks spoil the broth”

Symptoms and Consequences Documentation is overly complex,

unreadable, incoherent or defective No convergence and stability Conflicting interpretations between

architects and developers Unproductive meetings and

discussions

Typical Causes No designated product architect Degenerate or ineffective software

process Attempt to make everybody happy Gold plating… features added

based on proprietary interests, for future work, and so on

Example: SQL Standard Standard in 1989: 115 pages: Full

implementation by most vendors SQL92: 580 pages: Partial adoption SQL3: object-oriented, geospatial,

temporal-logic extensions SQL3 has become a dumping

ground for advanced database features

Known Exceptions “Tiger teams”: Experts in

individual domains, together for a short duration.

Max size of committee should be 6 to 10 people

Solution Reform the meeting process

Have a clock “Why are we here?” “What outcomes do we want?” Assign roles

Types of Meetings: Divergent (idea generation), Convergent (decisions), Information Sharing

Effective Meetings Frame the question Write responses silently Toss papers into a bin Distribute and readout Reach common understanding Eliminate duplicates Prioritize Discuss

AP: Swiss Army Knife Excessively complex class

interface Designer attempts to provide for

all possible uses of the class Too many interface signatures Makes it overly complex to use

AP: Reinvent the Wheel

“Our problem is unique”

Symptoms and Consequences Closed system architectures Replication of commercial software

functions Immature and unstable products Extended development cycles Schedule and budget overruns

Typical Causes No communication or technology

transfer between projects Absence of architecture process Assumption that system will be

built from scratch

Known Exceptions Research projects When development teams are at

logistically remote sites

Solution Architecture Mining Design patterns

In Part III… 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!