Successfully reported this slideshow.

Anti Patterns Siddhesh Lecture3 Of3


Published on

Anti Patterns - what not to do!

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Anti Patterns Siddhesh Lecture3 Of3

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