1. By Thomas Hutton

2.  Definition  AntiPattern Template  Benefits of Identifying AntiPatterns  Benefits of Understanding AntiPatterns

3.  “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.  “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 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.  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.  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.  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.  Why would one produce such a program? ◦ Too little time. ◦ General laziness. ◦ Technical Inability ◦ Changes to Requirements

10.  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.  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.  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 Name  Also Known As  Most Applicable Scale  Refactored Solution Name  Refactored Solution Type  Root Causes  Unbalanced Forces  Anecdotal Evidence

14.  Background  General Form  Symptoms and Consequences  Typical Causes  Known Exceptions  Variations

15.  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.  Refactored Solution Type ◦ Software ◦ Technology ◦ Process ◦ Role  Unbalanced Forces ◦ Management of “primal forces” – organizational pressures that occur

17.  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.  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.  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.  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.  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.  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.  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.  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.  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.  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.  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.  Projects that do no need standards ◦ Very small, quick, and have little complexity ◦ Be wary of falling into the One-Shot Deal AntiPattern

29.  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.  Stand alone  No hidden causes  Related to the people, technology and/or process

31. WebSphere MQ Monitoring

32.  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.  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.  Trust your intuition!  Talk to coworkers about your concerns. ◦ They have just as much at stake as you do.  Read a book.

35.  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. Increased Understanding of Best Practices!

37.  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.  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?sea rchId=797&recCount=25&recPointer=0&bibId=242 218&searchType=7 http://pltlib.wisconsin.edu/vwebv/holdingsInfo?sea rchId=797&recCount=25&recPointer=0&bibId=242 218&searchType=7