Definition AntiPattern Template Benefits of Identifying AntiPatterns Benefits of Understanding AntiPatterns
“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)
“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)
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
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
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.”
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.
Why would one produce such a program? ◦ Too little time. ◦ General laziness. ◦ Technical Inability ◦ Changes to Requirements
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)
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.
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
AntiPattern Name Also Known As Most Applicable Scale Refactored Solution Name Refactored Solution Type Root Causes Unbalanced Forces Anecdotal Evidence
Background General Form Symptoms and Consequences Typical Causes Known Exceptions Variations
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.
Refactored Solution Type ◦ Software ◦ Technology ◦ Process ◦ Role Unbalanced Forces ◦ Management of “primal forces” – organizational pressures that occur
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
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.”
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?
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
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.
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
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)
From our example: “I know how we can fix this problem! We’ll implement a standard.” “Standards are worthless.” “Just stick to the standards!”
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
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
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
Projects that do no need standards ◦ Very small, quick, and have little complexity ◦ Be wary of falling into the One-Shot Deal AntiPattern
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
Stand alone No hidden causes Related to the people, technology and/or process
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.
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.
Trust your intuition! Talk to coworkers about your concerns. ◦ They have just as much at stake as you do. Read a book.
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
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.
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