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!