anti patterns siddhesh lecture3 of3

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!