Anti Patterns Siddhesh Lecture2 Of3

1,026 views

Published on

Anti Patterns - what not to do!

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,026
On SlideShare
0
From Embeds
0
Number of Embeds
23
Actions
Shares
0
Downloads
34
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Anti Patterns Siddhesh Lecture2 Of3

  1. 1. Anti-Patterns Refactoring Software, Architectures and Projects in Crisis: Part 2 Siddhesh Bhobe
  2. 2. Last Week <ul><li>Definition </li></ul><ul><li>Motivation for AntiPatterns </li></ul><ul><li>Software Development AntiPatterns </li></ul>
  3. 3. In Part II… <ul><li>Recap </li></ul><ul><li>Software Architecture AntiPatterns </li></ul><ul><li>In Part III: </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
  7. 7. AP: StovePipe Enterprise <ul><li>“Can I have my own island (of automation)?” </li></ul><ul><li>“We’re unique!” </li></ul>
  8. 8. Stovepipe… <ul><li>Used to describe software systems with ad hoc architectures </li></ul><ul><li>Stovepipes need lot of maintenance </li></ul><ul><li>Repaired with whatever is at hand; hodgepodge of ad hoc repairs </li></ul>
  9. 9. Symptoms and Consequences <ul><li>Incompatible technology, terminology and approaches within the enterprise </li></ul><ul><li>Inability to extend </li></ul><ul><li>Lack of reuse and interoperability </li></ul><ul><li>Excessive maintenance costs </li></ul>
  10. 10. Typical Causes <ul><li>Lack of enterprise technology strategy </li></ul><ul><li>Lack of incentive to cooperate: competing business areas & executives </li></ul><ul><li>Lack of communication </li></ul><ul><li>Lack of knowledge of technology standards being used </li></ul><ul><li>Absence of horizontal interfaces </li></ul>
  11. 11. Known Exceptions <ul><li>Takeovers and Mergers </li></ul><ul><li>Wrapping some systems can be a temporary solution </li></ul>
  12. 12. Solution: Define Models <ul><li>Requirements Model </li></ul><ul><ul><li>Open Systems Reference Model </li></ul></ul><ul><ul><li>Technology Profile </li></ul></ul><ul><ul><li>Operating Environment </li></ul></ul><ul><ul><li>System Requirements Model </li></ul></ul><ul><li>Specifications Model </li></ul><ul><ul><li>Enterprise Architectures </li></ul></ul><ul><ul><li>Computational Facilities </li></ul></ul><ul><ul><li>Interoperability </li></ul></ul><ul><ul><li>Development Profile </li></ul></ul>
  13. 13. Open Systems Reference Model <ul><li>High Level Architecture </li></ul><ul><li>List of target standards for system development projects </li></ul><ul><li>IEEE POSIX 1003.0 standard </li></ul>
  14. 14. Technology Profile <ul><li>Define short-term standards plan </li></ul><ul><li>Reference model is flexible; Technology profiles mandate standards </li></ul><ul><li>US-DOD Joint technical Architecture </li></ul>
  15. 15. Operating Environment <ul><li>Defines product releases and installation conventions </li></ul><ul><li>Influence adoption of recommended environments </li></ul><ul><li>Variations should be supported locally at extra cost </li></ul>
  16. 16. System Requirements Profile <ul><li>Summary of key requirements for a family of related systems </li></ul><ul><li>Scopes out the system capabilities </li></ul><ul><li>Leads to enterprise wide planning </li></ul>
  17. 17. Enterprise Architecture <ul><li>Set of diagrams and tables that define a system or family of systems </li></ul><ul><li>Consider views of end users, developers, system operators and technical specialists </li></ul>
  18. 18. Computational Facilities Architecture <ul><li>Identifies key points of interoperability </li></ul><ul><li>APIs and data objects </li></ul><ul><li>Defines roadmap of priorities and schedules for the facilities </li></ul>
  19. 19. Interoperability Specification <ul><li>Technical details of a computational facility </li></ul><ul><li>APIs in IDL and common data object definitions </li></ul><ul><li>Created using architecture mining </li></ul>
  20. 20. Development Profile <ul><li>Implementation plans and developer agreements </li></ul><ul><li>Assure interoperability and successful integration </li></ul><ul><li>Specifies local extensions to APIs and conventions </li></ul>
  21. 21. AP: Stovepipe System <ul><li>“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!” </li></ul>
  22. 22. Symptoms and Consequences <ul><li>Single-system analogy of StovePipe Enterprise </li></ul><ul><li>Large semantic gap between architecture and implementation </li></ul><ul><li>Requirement changes are costly to implement </li></ul><ul><li>Maintenance is surprisingly expensive </li></ul><ul><li>Complies with paper requirements, but does not meet user expectations </li></ul>
  23. 24. Typical Causes <ul><li>Absence of common integration mechanism </li></ul><ul><li>Lack of abstraction </li></ul><ul><li>Insufficient metadata makes it difficult to extend and configure </li></ul><ul><li>Lack of architectural vision </li></ul>
  24. 25. Known Exceptions <ul><li>R&D, Prototypes and Mockups </li></ul><ul><li>Choice to use a vendor’s product and not reinvent the wheel can also lead to this. </li></ul>
  25. 26. Solution <ul><li>Component architecture providing flexible substitution of modules </li></ul><ul><li>Abstractions and reduces interfaces </li></ul><ul><li>Use of metadata </li></ul><ul><li>Decouple clients from services </li></ul>
  26. 28. AP: Vendor Lock-In <ul><li>“When I try to read the new data files into the older version of the application, it crashes my system” </li></ul><ul><li>“Our architecture is… What’s the name of our database again?” </li></ul>
  27. 30. Symptoms and Consequences <ul><li>Commercial product upgrades drive the application software maintenance cycle </li></ul><ul><li>Product varies significantly from advertised open systems standard </li></ul><ul><li>If upgrade is missed, repurchase and reintegration is necessary </li></ul>
  28. 31. Typical Causes <ul><li>Product differs from standards because there is no conformance process </li></ul><ul><li>Product selected based on marketing, and not on detailed technical inspection </li></ul><ul><li>Application software not isolated from the vendor product </li></ul><ul><li>Product more complex than required; results in complexity of the application </li></ul>
  29. 32. Known Exceptions <ul><li>When the single vendor provides most of the required functionality </li></ul>
  30. 33. Solution <ul><li>Isolate application from low level infrastructure </li></ul>
  31. 34. AP: Wolf Ticket <ul><li>Claims conformance to standards that have no enforceable meaning </li></ul><ul><li>Proprietary interfaces </li></ul><ul><li>Wolf Tickets: Illegal/invalid tickets to rock concerts </li></ul>
  32. 35. AP: Architecture by Implication <ul><li>“We’ve done systems like this before” </li></ul><ul><li>“There is no risk. We know what we are doing” </li></ul>
  33. 36. Symptoms and Consequences <ul><li>Lack of planning and specification of architecture for software, hardware, communications, persistence, security, systems management </li></ul><ul><li>Hidden risks </li></ul><ul><li>Unacceptable levels of performance, usability, requirements acceptance </li></ul>
  34. 37. Typical Causes <ul><li>No risk management </li></ul><ul><li>Overconfidence of managers, architects and/or developers </li></ul><ul><li>Reliance on previous experience which may differ in critical areas </li></ul><ul><li>Gaps in system engineering </li></ul>
  35. 38. Known Exceptions <ul><li>Repeated solution, with minor difference like installation scripts </li></ul><ul><li>Exploratory projects </li></ul>
  36. 39. Solution <ul><li>Organized approach to systems architecture definition </li></ul><ul><li>Goal-Question Architecture </li></ul><ul><li>4 + 1 Model View: Rational Rose (Logical, Use-case, process, implementation and deployment views) </li></ul>
  37. 40. AP: Warm Bodies <ul><li>Also known as Body Shop, Mythical Man-Month </li></ul><ul><li>Large projects with huge teams </li></ul><ul><li>Adding more staff to ongoing software project does not help! (Mythical Man-Month, 1979) </li></ul><ul><li>Small, compact teams make more sense </li></ul><ul><li>Recommended: 4 people, 4 months </li></ul>
  38. 41. AP: Design by Committee <ul><li>“A camel is a horse designed by a committee” </li></ul><ul><li>“Too many cooks spoil the broth” </li></ul>
  39. 42. Symptoms and Consequences <ul><li>Documentation is overly complex, unreadable, incoherent or defective </li></ul><ul><li>No convergence and stability </li></ul><ul><li>Conflicting interpretations between architects and developers </li></ul><ul><li>Unproductive meetings and discussions </li></ul>
  40. 43. Typical Causes <ul><li>No designated product architect </li></ul><ul><li>Degenerate or ineffective software process </li></ul><ul><li>Attempt to make everybody happy </li></ul><ul><li>Gold plating… features added based on proprietary interests, for future work, and so on </li></ul>
  41. 44. Example: SQL Standard <ul><li>Standard in 1989: 115 pages: Full implementation by most vendors </li></ul><ul><li>SQL92: 580 pages: Partial adoption </li></ul><ul><li>SQL3: object-oriented, geospatial, temporal-logic extensions </li></ul><ul><li>SQL3 has become a dumping ground for advanced database features </li></ul>
  42. 45. Known Exceptions <ul><li>“Tiger teams”: Experts in individual domains, together for a short duration. </li></ul><ul><li>Max size of committee should be 6 to 10 people </li></ul>
  43. 46. Solution <ul><li>Reform the meeting process </li></ul><ul><ul><li>Have a clock </li></ul></ul><ul><ul><li>“Why are we here?” </li></ul></ul><ul><ul><li>“What outcomes do we want?” </li></ul></ul><ul><ul><li>Assign roles </li></ul></ul><ul><li>Types of Meetings: Divergent (idea generation), Convergent (decisions), Information Sharing </li></ul>
  44. 47. Effective Meetings <ul><li>Frame the question </li></ul><ul><li>Write responses silently </li></ul><ul><li>Toss papers into a bin </li></ul><ul><li>Distribute and readout </li></ul><ul><li>Reach common understanding </li></ul><ul><li>Eliminate duplicates </li></ul><ul><li>Prioritize </li></ul><ul><li>Discuss </li></ul>
  45. 48. AP: Swiss Army Knife <ul><li>Excessively complex class interface </li></ul><ul><li>Designer attempts to provide for all possible uses of the class </li></ul><ul><li>Too many interface signatures </li></ul><ul><li>Makes it overly complex to use </li></ul>
  46. 49. AP: Reinvent the Wheel <ul><li>“Our problem is unique” </li></ul>
  47. 50. Symptoms and Consequences <ul><li>Closed system architectures </li></ul><ul><li>Replication of commercial software functions </li></ul><ul><li>Immature and unstable products </li></ul><ul><li>Extended development cycles </li></ul><ul><li>Schedule and budget overruns </li></ul>
  48. 51. Typical Causes <ul><li>No communication or technology transfer between projects </li></ul><ul><li>Absence of architecture process </li></ul><ul><li>Assumption that system will be built from scratch </li></ul>
  49. 52. Known Exceptions <ul><li>Research projects </li></ul><ul><li>When development teams are at logistically remote sites </li></ul>
  50. 53. Solution <ul><li>Architecture Mining </li></ul><ul><li>Design patterns </li></ul>
  51. 54. In Part III… <ul><li>Software Project Management AntiPatterns </li></ul>
  52. 55. References <ul><li>AntiPatterns: William Brown, Raphael Malveau et al (PSPL Library S-76) </li></ul><ul><li>http://www.antipatterns.com/thebook.htm </li></ul><ul><li>Similar presentation at http://www.mitre.org/support/swee/html/67_mccormick </li></ul>
  53. 56. Thank You!

×