anti patterns siddhesh lecture3 of3
Post on 06-May-2015
659 Views
Preview:
DESCRIPTION
TRANSCRIPT
Anti-PatternsRefactoring Software, Architectures and Projects in Crisis: Part 3
Siddhesh Bhobe
Previous Lectures Definition Motivation for AntiPatterns Software Development
AntiPatterns Software Architecture AntiPatterns
In Part III… Recap 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 StovePipe
Enterprise StovePipe System Vendor Lock-in Wolf Ticket Warm Bodies
Architecture by Implication
Design by Committee
Swiss Army Knife Reinvent the
wheel
Software Project Management AntiPatterns
AP: Blowhard Jamboree Technical decisions influenced by
external critical reports Developers spend time addressing
unfounded management concerns Solution: Develop in-house
technical experts in key technical areas
AP : Analysis Paralysis
“We need to redo this analysis to make it more object-oriented, and use much more inheritance to get lots of reuse”
Symptoms and Consequences Multiple project restarts Design and implementation issues
mentioned in the analysis phase Design patterns get mentioned Complexity of system increases Analysis is speculative, and does
not involve the user
Typical Causes Management has more faith in it’s
ability to analyze than implement Assumes waterfall process Wants to be perfect in the analysis Goals in analysis not well defined
Known Exceptions No exceptions
Solution Incremental Development Internal Increments
Developing infrastructure Minimizes rework
External Increments User validation Customer informed about progress Involves some throwable code
AP: Viewgraph Engineering Developers stuck preparing
viewgraphs and documents No software Management doesn’t obtain
development tools Developers use office automation
software Frustrating
Solution Construct prototypes Mockups
Simulation Can be used to assess requirements
and user acceptance Engineering Prototypes
Operational functionality Architecture validation
AP: Death by Planning
“We can’t get started until we have a complete program plan”
“The plan is the only thing that will ensure our success”
Over Planning
Glass Case Plan Plan produced at the start of the
project Never updated Gives management a “good feel” Planning ceases when project starts
Becomes increasingly inaccurate
Detailitis Plan Continuous exercise involving most of
senior management and developers Hierarchical sequence of plans which
show unnecessary level of detail Gives the perception that the project is
under control Planning continues after project starts
Symptoms and Consequences Inability to plan at a pragmatic level Focus on costs rather than delivery Ignorance of status of development Failure to deliver critical milestones Projects overruns: further
investment, crisis management, cancellation, loss of key staff
Typical Causes Lack of pragmatic approach to
planning, scheduling and capturing progress
No up-to-date plan showing progress Overzealous planning Ignorance Sales aid for contract acquisition Forced customer compliance
Known Exceptions Never
Solution Identify deliverables Milestones Weekly updates of progress Gantt Charts Baseline early and rarely Keep contingency periods Minimum time frames for tasks
AP: Fear of Success Obsessive worry about things that
can go wrong Happens towards the end of a
project Solution: Management should
recognize success, even if the external result is ambiguous, Mentoring by Seniors
Group Dynamics in a Project Phase 1: Group Acceptance Phase 2: Individuals assume key
roles, Team Building occurs Phase 3: Work, Personality issues Phase 4: Termination, Concerns
about future life cycle
AP: Corncob
“Why is Bill so difficult to work with?”
“I own development and I have made a decision that you will follow”
Symptoms and Consequences Someone always disagrees with
objectives or essential processes Team finds it difficult to progress Management unwilling or unable to
address the damage it causes Politics, too many changes Often, a manager who is not under the
direct authority of a senior software development manager or project manager
Typical Causes Management supports the
behavior by not acknowledging it Hidden agenda which conflicts with
team goals Fundamental disagreement that
cannot be resolved No accountability
Known Exceptions When the team is ok with it When a dominant person is
required to defend an existing architecture from inappropriate changes
Solution Eliminate management support Tactical: Transfer, Isolate,
Question Operational: Corrective interview,
Out-placement Strategic: Empty department,
Eliminate
Versions of Corncobs Corporate Shark: Survives through
relationships with others; Avoid them Bonus Monster: Cutting corners,
encourage inter-departmental conflicts Firebrand: Deliberately creates political
emergency, then emerges as hero Egomaniacs: Obsessed with own image Loose Cannon: Destructive effect on
image and morale
More Corncobs… Technology Bigot: promulgates
marketing hype Saboteur: Someone about to exit;
manipulates work environment to advantage of next assignment; try to make colleagues leave through rumors
Careerist: Makes decisions for own career advancement
Anachronist: Resist innovation due to own incompetence
AP: Intellectual Violence Somebody who understands a
technology, theory or buzzword uses it to intimidate others in a meeting
Breakdown of communication Solution: Cross-training,
Information Sharing, Mentoring
Irrational Management
“Don’t bother asking: They’ll just say no”
“What do we do now?”
“Who’s running this project?”
Symptoms and Consequences Irrational decisions by managers Knee-jerk reactions Increased staff frustration Project delays Exploitation by corncobs
Typical Causes Lack of ability to manage
development staff, other managers, processes
No clear vision and strategy Cannot make decisions Fears success Ignorant of state of project and
deliverables
Known Exceptions Ideally never However, a “golden child” with
guru-level capabilities in certain areas can be tolerated till long-term solution is planned
Solution Admit you have a problem and get help Understand the staff Provide clear, short-term goals Share a focus Look for process improvement Facilitate communication Manage communication mechanisms Do not micro-manage
Situation Analysis List all concerns Rate concerns for seriousness,
urgency, growth potential Add up scores Prioritize Assign resolvable items to
appropriate staff Work on top priority items on the list
Decision Analysis Define scope of decision to be analyzed Identify alternatives Define decision criteria Divide between essentials and desirable Eliminate those that do not satisfy all
essentials Fact finding; tabulation of scores Be aware that rational choice may not be
acceptable by managers or customers
AP: Smoke and Mirrors Demo systems interpreted by end users
as representational of production-quality capabilities
Management makes commitments to get business
Tough for developers Ultimate loser is end user Solution: Management of expectations;
promise less than you will deliver
AP: Project Mismanagement
“What went wrong? Everything was going so fine!”
All you need in life is ignorance and confidence.. then success is sure!
- Mark Twain
Symptoms and Consequences Design difficult to implement Code reviews happen infrequently Test design is difficult because
behavioral guidelines not clear Too much thrashing in integration
phase Defect reports escalate towards end
Typical Causes Key activities overlooked
Technical planning (architecture) Quality control: Inspection and testing
Ineffective risk management
Known Exceptions Never
Solution Risk management
Managerial: Processes and Roles Common Project Failure Points: Cost
overruns, premature termination, development of wrong product, technical failure
Quality: Effectiveness of planning, product and architecture definition, documentation
AP: Throw it over the wall Code finished; no testing; no
documentation Guidelines taken too literally
without understanding purpose Communicate technical
documentation through tutorials, training sessions
AP: Fire Drill Project initiated, but staff delays design and
development till various techno-political decisions are resolved at management level
Situation announced at “all hands” meeting, where management makes unrealistic demands
Compromises made Sheltering: Shield internal teams from
external factors; handle it at a different level
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!
top related