1 / 38

AntiPatterns

AntiPatterns. By Thomas Hutton. Overview. Definition AntiPattern Template Benefits of Identifying AntiPatterns Benefits of Understanding AntiPatterns. Definition.

amalia
Download Presentation

AntiPatterns

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. AntiPatterns By Thomas Hutton

  2. Overview • Definition • AntiPattern Template • Benefits of Identifying AntiPatterns • Benefits of Understanding AntiPatterns

  3. Definition • “Software engineering consists of all the technical activities that are performed to build the project deliverable (the “just build it” activities). Software engineering deals with construction the components, integrating them, verifying them, validating them, and finally combining all of the components into a product and convincing the customer to accept delivery of it.” (Chemuturi, 19)

  4. Definition • “Mechanism to describe a commonly occurring solution to a software development need that generates significantly negative consequences.” (Brown, XXVII) • “An AntiPattern is a repeated application of code or design that leads to a bad outcome.” (Dudney, XIX)

  5. A Matter of Perspective • A process that works for one team or project may not work for another. • Not necessarily an AntiPattern • Not limited to any single area. • Project Management • Analysis/Design • Code

  6. Yin Yang • Software Engineering processes are based off best practices compiled from experiences. • AntiPatterns are a key building blocks for these processes – they represent failed processes. • Learning from mistakes

  7. Example • An programming assignment is due in two days. Due to your class load, you do not have the considerable amount of time to correctly produce a proper solution. As a result, you think to yourself “I just need to hand something in. At least I will get some credit.”

  8. One-Shot Deal • Also known as: The Quick’n’Dirty • Understanding of the project is that the code must be produced quickly and will not be maintained later.

  9. Root Cause • Why would one produce such a program? • Too little time. • General laziness. • Technical Inability • Changes to Requirements

  10. Common Forms • Prototypes • Built with the idea that the code may be scrapped, but will provide data on the direction of the project. • “This implies, practically speaking, that programmers must learn to disregard their notions of “professional pride” and produce what they typically thought of as amateurish code, quick-and-dirty hacks and kludges that absolutely will not stand the test of time.” (Borenstein, 118)

  11. Common Forms • The Tool • Usually single developers given a mission to build a program to quickly complete a simple task. • The Retrofit • Demand for a new architecture while functionality is untouched.

  12. Symptoms • Leads to programs that cannot be maintained • Generally programs are of poor quality • Programs are unlikely produce proper output in test scenario • Lack of documentation • Inefficient or dead code

  13. AntiPattern Template • AntiPattern Name • Also Known As • Most Applicable Scale • Refactored Solution Name • Refactored Solution Type • Root Causes • Unbalanced Forces • Anecdotal Evidence

  14. Detailed Template • Background • General Form • Symptoms and Consequences • Typical Causes • Known Exceptions • Variations

  15. Template - Details • Most Frequent Scale • Global: Design issues across all systems. • Enterprise: Coordination/communication across an organization • System: Coordination/communication across applications. • Application: Individual application. • Framework: Macro-level. • Micro-Architecture: Repeated use of solutions. • Object: Especially reusable objects.

  16. Template - Details • Refactored Solution Type • Software • Technology • Process • Role • Unbalanced Forces • Management of “primal forces” – organizational pressures that occur

  17. Apply the Template • Name: One-Shot Deal • AKA: Quick’n’Dirty • Scale: Enterprise • Solution Name: Aim Before You Shoot • Solution Type: Process • Root Causes: Sloth, Haste, or Ignorance • Unbalanced Forces: Management of IT Resources

  18. Anecdotal Evidence • From our example: “I just need to hand something in. At least I will get some credit.” • “We don’t need documentation.” • “This isn’t a major release, we just need something now.” • “If we don’t get this done now, we won’t ever get it done.”

  19. Solution • Aim Before You Shoot • Think about the implications of creating software without documentation. • Ask if there is any chance this program will need to be maintained. • Is anyone paying for this software? • How long is the software expected to be used? • How difficult is the software to create?

  20. Exceptions • Prototypes • Managed expectations can lead to a prototypes achieving their goal: to provide an example. • Consider developing prototypes in a different language. • Automated Source Code Control • Formal Defect Tracking • Standards for Documentation/Testing

  21. Another Example • As a project manager, you are worried about the integrity and quality of code your developers are producing. So far, the code seems to fit into the design scheme and passes test cases, but you question the maintainability of the code. Therefore, you tell all of your developers to implement a new standard.

  22. The Standards • Also Known As: The Necessary Evil • Generally a problem with process • Can be caused by pride or ignorance • Often managers fail to understand the complexity of new standards, reason to have standards at all

  23. Problems • Developers outright refuse to implement the new standards • Schedule is not changed to reflect the time and effort necessary to implement a standard • “Organizations pay lip service to quality standards or guidelines or… they implement the standards/guidelines poorly.” (Chemuturi, 213)

  24. Anecdotal Evidence • From our example: “I know how we can fix this problem! We’ll implement a standard.” • “Standards are worthless.” • “Just stick to the standards!”

  25. Root Causes • Additional work created by implementing a new and/or complex standard • Organization does not value standards and/or is not committed to implementing them • Selected standard is overly complex

  26. Apply the Template • Name: The Standards • AKA: The Necessary Evil • Scale: System • Solution Name: Back to Zero • Solution Type: Process • Root Causes: Ignorance, Sloth, Apathy, Narrow-Mindedness, or Pride • Unbalanced Forces: Management of Complexity

  27. Refactored Solution • Return to Zero • Look at the what is necessary to uphold your expectations for quality • Match the expectation to the standard • Look for standards that support maintenance but are flexible

  28. Exceptions • Projects that do no need standards • Very small, quick, and have little complexity • Be wary of falling into the One-Shot Deal AntiPattern

  29. Interacting AntiPatterns • AntiPatterns can occur in sequence, meaning that one problem often leads to another. • Solving the first quickly may solve the subsequent AntiPatterns. • Generally due to lack of control

  30. Isolated AntiPatterns • Stand alone • No hidden causes • Related to the people, technology and/or process

  31. Personal Experience WebSphere MQ Monitoring

  32. Benefits to Identifying AntiPatterns • Avoid or reduce the effects of the AntiPattern! • The sooner you identify a potential problem, the more likely you are to find a solution. • Remember failures – those experiences will help you succeed in the future.

  33. How to Identify AntiPatterns • Chronicle problems that occur and the solution attempted. • Reuse or refine good solutions • Abandon bad solutions • Ask yourself “Why did this solution work or fail?” • The goal is to be consciously aware of the problem, what caused it to occur and how to solve it.

  34. How to Identify AntiPatterns • Trust your intuition! • Talk to coworkers about your concerns. • They have just as much at stake as you do. • Read a book.

  35. Benefits to Understanding AntiPatterns • Aligned with the goals of software engineering • On time delivery • Cost within budget • Customers happy with delivered software • Avoidance of AntiPatterns • Prior knowledge is key

  36. Benefits to Understanding AntiPatterns Increased Understanding of Best Practices!

  37. Sources • Borenstein, Nathaniel S. Programming as If People Mattered: Friendly Programs, Software Engineering, and Other Noble Delusions. Princeton, NJ: Princeton UP, 1991. Print. • Brown, William J., Hays W. McCormick, and Scott W. Thomas. AntiPatterns in Project Management. New York: Wiley, 2000. Print.

  38. Sources • Chemuturi, Murali, and Thomas M. Cagley. Mastering Software Project Management: Best Practices, Tools and Techniques. Ft. Lauderdale, FL: J. Ross Pub., 2010. Print. • Dudney, Bill. J2EE Antipatterns. Indianapolis, IN: Wiley Pub., 2003. Print. • Found online via school library at http://pltlib.wisconsin.edu/vwebv/holdingsInfo?searchId=797&recCount=25&recPointer=0&bibId=242218&searchType=7

More Related