Anti-Patterns

ANTI-PATTERNS Belgi Özen Sr. Application Designer

Outline Anti-Pattern Fundamentals Management Anti-Patterns Poject Management Anti-Patterns Programming Anti-Patterns Software Design Anti-Patterns Methodological Anti-Patterns Conclusion References Questions & Answers

1. AntiPattern Fundamentals 1.1 What’s an Anti-Pattern? 1.2 Why do we Need Them? 1.3 Samples 1.4 Reference Model(Concepts that Depicts AntiPatterns) 1.5 Difference Btw Design Patterns & Anti-Patterns 1.6 Structure of an Anti-Pattern

1.1 What’s an Anti-Pattern? An AntiPattern describes a commonly occurring solution to a problem that generates decidedly negative consequences.. It identif ies mistakes committed in software development and offer the right solutions . There must be at least 2 key elements for antipatterns; a) Repeated pattern of action,process or structure causing bad consequences rather than benefical results(init. it seems good) b) A refactored solution that is clearly documented, proven in actual practice and repeatable. Anti - Patterns are derived by looking at the negative solutions. The purpose of creating a catalouge of antiPatterns is so they can be recognized and refactored .

1.1 Cont. Developed to complement the existing fundamental software patterns (GoF etc.) Anti-Patterns also identify the so-called good solutions applied under the wrong context or situation.

1.2 Why do we Need Them? 5/6 of software projects are regarded as failures 1/3 of software projects are canceled 50 years of software development —> still the same fundamental problems are encountered over and over again no generic preventive actions for avoiding the problems no generic countermeasures for mitigating the effects of the problems Possible solution: AntiPatterns ? Provide a method of efficiently mapping a general situation to a specific class of solutions. It gives the IT industry a common vocabulary and means to discuss and mitigate the common problems

1.2 Cont. Consistent reasons, common misunderstanding of the context and classic mistakes lead to bad designs and bad software. Through AntiPatterns we will be able to identify the reasons for such mistakes and failures on time to prevent serious consequences.

1.3 Samples I’ll give some simple examples here to show that anti-apatterns is no just about repeated bad programming or designs. It’s actually a LARGE CONCEPT that may be about anything in SOFTWARE DEVELOPMENT LIFECYCLE(It may be about Project manager, IT directors, software development actors, or it may be about Project managment subjects, Software Team management style of IT directors etc…)

1.3 Example : Mini AntiPattern: Robot “ Oh no we cannot do anything to the module before John comes back from his two-month holiday (in Bali)!” “ I am a guru. I’d like to work alone, it’s just my way of doing things.” “ I don’t know about it. Ask John, he has written the code for almost all of our key components.” Problem: A seemingly irreplaceable person who intentionally or unintentionally becomes the single point of failure and bottleneck in the software project ( Bizde de çok var bu durum; Bilgi dağılmayınca herşeyi çok iyi bilen temel kişiler olabiliyor ) Root causes : Avarice (kazanmak elde etmek için aşırı istek), Pride Refactored solution : interaction between developers, constant peer reviews, competence transfer, mentoring help to less experienced and busy developers Avarice

1.3 Ex2: Executive Decision Making AntiPattern Avarice

1.4 Differences with Design Patterns Design Patterns AntiPatterns Time passes yielding new context Problem Solution Consequences Related Solutions Benefits Context & Forces Symptoms & Consequences Context & Causes Consequences Related Solutions Benefits Refactored Solution AntiPattern Solution

1.4 Cont W hile Patterns help us to identify and implement procedures, designs and codes that work, AntiPatterns do the exact opposite; they let us focus on the development detonators, architectural tripwires, and personality booby traps that can spell doom for the project Design pattern becomes an antipattern when it causes more problems than it solves . Procedural programming was a great design pattern in the 60’s and 70’s ; Today it is an AntiPattern

1.5 Reference Model They are the aspects that forms/creates AntiPatterns in Software Project Development.. They can be classified as 1) Root Causes They provide fundamental context and situations for the AntiPattern 2) Primal Forces(issues, concerns ) They influence the decision making 3) Software Design Model Level They define architectural scales; each pattern has a most applicable scale

1.5.1 Root Causes R oot causes are the mistakes committed during the development cycle leading to effort/cost over runs, shifts on schedule etc. Main reasons are Haste(Acele, Hızlı yapma isteği) Eksik test, sadece çalışsın yeter tarzı kod, kalitesiz kod Apathy (Kayıtsızlık, İlgisizlik) Parçalara bölmeme, sorumlulukları dağıtmama(kararlı mı yoksa dinamik kod mu istiyoruz).. Developer ve project manager bilinen sorunları çözmekte ve kabul etmekte isteksizdir. Narrow-Mindedness(Dar görüşlülük, Yetkinlik eksikliği) Kabul görmüş çözümleri sonuca gitmek için kullanmama,direnç gösterme Sloth(Tembellik, Uyuşukluk) Kolay ve kısa yolu seçerek kötü kararlar verme; konfigürasyon toolu kullanmama, sık sık interface değişiklikleri.. Avarice(Tamahkar, açgözlü, aşırı istekli) Yazılım gereğinden fazla esnek, olası olmayan detayları içermemeli

1.5.1 Root Causes Yeterince yalıtılmamış kod(interface programming, abstraction) yüzünden gelen aşırı complexity.. Gereğinden fazla büyük sistemler(bir çok iş aynı yerde birleştirilmiş) Ignorance(İhmalkarlık) Sistem detaylarını öğrenmede yetersizlik/isteksizlik Büyük sistem resmi(interfaceleri) yerine küçük kod interfacelerine odaklanma Detayları saklamak için yeterince kodu WRAP etmeme Lack of Layering(Yeterince katman yaratmama; n-tier katman) Pride(Gurur) Gereksiz yeni tasarımlar peşinde koşma Burada bunu bilen yok yaklaşımı ile gerçekten gerekmediği durumlarda show kodu yazma Tekerleği baştan bulma(toString javada varken character işlemleri ile sıfırdan yazmamak lazım) sistem gereksinimlerini ihmal etme Yeterince freeware,opensource yazılımdan faydalanmama

1.5.2 Primal Forces Forces or concerns that exist within a decision-making process Forces that are addressed lead to benefits Forces that remain unresolved lead to consequences For any given software problem there are a number of forces that can influence a given solution HORIZANTOL FORCES (Accross-Domains; primal forces; influences several components, modules..LIKE SMG designs; Good designs/decisions may improve overall CoreFinans operations, whereas, bad designs may affect all components and all core modules..Worse than that it may cause the whole software become unfunctional.) VERTICAL FORCES (Problem-domain specific)

1.5.2 Cont. Management of functionality (Meeting the requirements) Good control and management of functionality will make sure that the developed software will meet the requirements of the customer . Management of performance • Meeting required speed and operation Management of complexity(Defining abstractions) We should consider how to make the design decisions such that we don't end up with too much of complexity. F ailure to look into effective abstractions will result in an excessively complex and costly system thereby making future enhancements and scalability almost impossible.

1.5.2 Cont. Management of change( Controlling the evolution of the software T he adaptability, flexibility and portability of the developed software Management of IT resources(People and IT artifacts) N on-availability of a special hardware or software package during the life-cycle of the development process. This will lead to schedule delay and associated cost escalation Management of technology(Controlling technology evolution)

1.5.3 Software Design Model Level A good architectural design is needed to manage the code easily. The design should be open to implement new requirement easily. One of the key benefits of architecture is the separation of concerns, which means, rather than tackling all the problems at once, partitioning the problem into solvable elements

1.6 Structure of an Anti Pattern • Description of the general form • Symptoms on how to recognize the general form • Causes that led to the general form (Önceki bölümlerde anlatıldı) • Consequences of the general form (Kötü sonuçları) • Refactored solution on how to change the AntiPattern into a healthier situation (Ne yapılmalı)

2.Management Anti-Patterns 2.1 Blowhard Jamboree M anagers read too much in the trades written by "industry" experts . Many of these so-called experts are misinformed; Often, the information they are reporting is second-hand. Rarely is there any hands-on research and experience backing up their conclusions. Refactored Solution: An in-house expert on each key technology is an invaluable asset to every organization. He or she can discriminate between facts, misinformation, and opinions in popular media and other reports. If your organization does not have in-house experts, appoint staff to follow particular technologies and develop their expertise through reading, training courses, standards activities, and hands-on experiments, such as p rototyping

2.2 Analysis Paralysis(Waterfall) General Form  Goal is to achieve perfection and completeness of the analysis phase.  It is characterized by turnover, revision of the models, and the generation of detailed models that are not so useful. “ We need to redo this analysis to make it more object-oriented” “ I have to know a lot more about the system before I can change anything. ” Sympthoms & Consequences Cost of analysis exceeds expectation without a predictable end point. There are multiple project restarts and much model rework, due to personnel changes or changes in project direction. Design and implementation issues are continually reintroduced in the analysis phase.

2.2 Cont  The complexity of the analysis models results in complex implementations, making the system difficult to develop, document, and test.  Multiple project restarts—now we know enough/more and can do it right this time Typical Causes  The management process assumes a waterfall progression of phases. In reality, virtually all systems are built incrementally . Management insists on completing all analysis before the design phase begins. Management is unwilling to make firm decisions about when parts of the domain are sufficiently described

2.2 Cont (yönetim belirli konularda kesin karar almalı; kabuller yapmalı) The project vision and focus on the goal/deliverable to customer i s diffused. Analysis goes beyond providing meaningful value. Refactored Solution  Incremental Development(Iterations)  Use spiral process model instead of waterfall model—design a little, build a little; risk management

2.3 CornCob( difficult people) General Form A difficult person (the Corncob) causes problems through destructive behaviors for a software development team or, even worse, throughout an enterprise. They impact the team through various means: technical, political, and personal. They focus much more on politics than technology . They are usually experts at manipulating politics at personal and/or organizational levels. Technology-focused people can become easy victims of the Corncob's tactics.

2.3 CornCob Consequences A development team or project is unable to make progress because someone disagrees with their key objectives or essential processes and continually tries to change them. Political forces create an environment where it's difficult to keep technical discussions on track. One person continually raises objections, under the guise of concern, which are intractable: performance, reliability etc. The destructive behavior is well known to many people in the enterprise, but it's tolerated and supported (in some way) by management because they are unaware of, or unwilling to address, the damage it causes.

2.3 CornCob Causes Management doesn't isolate the group from internal and external forces, and has inappropriately allocated roles to staff, who abuse them for their own ends; even worse, management has failed to allocate accountability at all. Hidden Agenda; – In most industries, senior IT managers are competing with each other – Negative training or background. There is a fundamental disagreement between team members that no amount of communication can resolve.

2.3 CornCob Refactored Solution Solutions(strategic, operational, tactical) Transfer the responsibility ( turn the responsibility for planning and resolution over to the person who raises the concerns ) Isolate the issue( the group to discuss and frame the key objections, then try to gain consensus to overrule the objector. A straw poll is an effective technique for revealing group feeling ) Question the question ( When the Corncob uses ambiguous or "loaded" words or phrases, ask him or her to clarify their meaning ) Corrective Interview, Friendly Outplacement (recommend him to headhunters)

2.3 CornCob Refactored Solution(http://sourcemaking.com/antipatterns/corncob) Transfer corncobs to the same group Empty departments( Managers who are themselves difficult can be transferred to departments in which they are the only employee ,”get the message and retire” Corporate Shark( A Corporate Shark is an experienced manager whose career consists of managing relationships rather than his or her technical expertise, which may, as a result, be long neglected. Sharks survive by who they know not what they know. The Corporate Shark knows how to "work the system," and can easily create difficult political situations for those focused on technical issues. )

2.4 Smoke and Mirrors General Form Yemek yemek için  müşteriye yapılabilirliğin ötesinde sözler vermek Yazılım geliştirme ekibini zor duruma sokar.. Sonuçta kaybeden müşteri olur; zamanında ürünü alamaz; gecikmeli aldığında bile ürün artık bakımı yapılabilir bir ürün olmaz.. Yazılım grubu vs. kredi kaybeder.. Refactored Solution Beklentiler iyi yönetilmeli; müşterilere teslim edilebileceğinden daha azının verileceği kabul ettirilmeli; normali yapıldığında bile extra memnuniyet yaratmış oluruz ve devamlı müşteri kazanmış oluruz.

3.Project Management Anti-Patterns Intellectual Violence (solution  mentoring, encourage to share knowledger) Death March ( Everyone knows that the project is going to be a disaster - except the CEO. However, the truth remains hidden and the project is artificially kept alive until the Day Zero finally comes . Employees are pressured to work late nights and weekends on a project with an unreasonable deadline. ) Project MisManagement

4.Development Anti-Patterns Blob Lava Flow Continous Obsolescense Ambiguous ViewPoint Functional Decomposition Poltergeists Boat Anchor Golden Hammer DeadEnd

4.Development Anti-Patterns Spaghetti Code Input Kludge Walking Through a MineField Cut-Paste Programming MushRoom Management

4.1 Blob General Form  One class for processing(controller GOD CLASS), others encapsulate data..(Old ATM Dispatcher, Hesap.java)  The Blob is often accompanied by unnecessary code, making it hard to differentiate between the useful functionality of the Blob Class and no-longer-used code (has the nature of proced. design) Consequences  Single class with a large number of attributes, operations, or both . A class with 60 or more attributes and operations usually indicates the presence of the Blob .. A disparate collection of unrelated attributes and operations encapsulated in a single class (Most of classes in Core Finans) The Blob Class is typically too complex for reuse and testing

4.1 Blob  The Blob Class may be expensive to load into memory, using excessive resources, even for simple operations. Causes Lack of Object-Oriented Architecture (dev teams and designers; lack of abstract. skills) Procedural Design Experts are Chief Architects Lack of Any Architecture (components and interactions are not well defined) Too Limited Changes( “I did change only a small part  ”) Lack of Architectural Review during Coding Specified Disaster (architecture is speelt out at Requirement analysis rather than Requirement specification phase)

4.1 Blob Refactored Solution The architecture of the system is very important!! Distribute Responsibilities uniformly (reallocate beahviours to some of the encapsulated data objects so that they are more capable) Isolate effect of changes Identify and categorize attributes and behaviours Find “Natural Homes” (very clear; must objects)

4.2 Lava Flow(Dead Code) General Form (Alp Şehiç Cesareti)  Someone in the past wrote some piece of code that nobody knows whether it is useful or not now. But in case of causing a production bug, nobody deletes the code(Alp Şehiç gibi cesur değil kimse  )  “ Leave the code alone; it does not harm anything” Consequences  Lots of dead Code;  Unnecessarily complex methods, important looking functions;  This “lava” code may be reused in other areas.  Difficulty in documentation Causes  Single developer wrote the code(lonely wolf)

4.2 Lava Flow  Uncontrolled distribution of unfinished code  Repeatitive development Process (goals of project are unclear often change)  Difficulty in removing the unused code from hundreds of files of source code.  Lava code can be expensive to load into memory Refactored Solution  Ensure architecture precedes production code development; backup architecture(KYS), check architectural compliance.  Avoid architectural changes during active development

4.2 Lava Flow Management should postpone development until a clear architecture has been defined(in cases where Lava Flow already exists) To avoid it,I t is important to establish system-level software interfaces that are stable, well-defined, and clearly documented System discovery(locate the components that are really used; the lines of code that may be deleted safely); we need experienced software detective  Establish system-level software interfaces that are stable,well defined and clearly documented

4.3 Ambiguous Viewpoint Problem  OOA&D models often do not explain their viewpoint.  Often implementation view—least useful Refactored Solution  the business viewpoint; specification viewpoint, and the implementation viewpoint

4.4 Functional Decomposition General Form (http://sourcemaking.com/antipatterns/functional-decomposition) When developers are comfortable with a “main” routine that calls numerous subroutines, they may tend to make every subroutine a class, ignoring class hierarchy altogether The resulting code resembles a structural language such as Pascal or FORTRAN in class structure ; it can be very complex, difficult to manage by time.. It’s usually cheaper in the long run to spend the money on object-oriented training or just hire new programmers who think in objects

4.4 Functional Decomposition Consequences Classes with “function” names such as Calculate_Interest or Display_Table may indicate the existence of this AntiPattern. All class attributes are private and used only inside the class. Classes with a single action such as a function. Absolutely no leveraging of object-oriented principles such as inheritance and polymorphism No hope of ever obtaining software reuse. Causes  Result of experienced non oo-developers who design and implement the application in ana OOP language.  When the implementers are clueless about object orientation, it

4.4 Functional Decomposition doesn’t matter how well the architecture has been designed; they simply won’t understand what they’re doing. Refactored Solution Define an analysis model for the software to explain the critical features of the software from the user’s point of view During the solution, provide detailed documentation of the processes used as the basis for future maintenance efforts. F ormulate a design model that incorporates the essential pieces of the existing system .  For classes that fall outside he design model; try to make the class as a part of the existing classes(if it has single method); Combine several classes into one class logically; create utility classes from several classes(if they do not keep state; just funct.)

4.5 Boat Anchor General Form It is a piece of software or hardware that has no useful purpose in the project. It may be purchased at the design stage. But later on it is seen that that it will not be useful. A policy or programmatic relationship may require the purchase and usage of a particular piece of hardware or software. VIP Marketing(targets the sales pitch at senior decision makers who have buying authority ) A commitment to the product is made without proper technical evaluation. Refactored Solution

4.5 Boat Anchor Refactored Solution H ave a good technical back-up associated with efficient engineering practices that would provide the appropriate advice in the selection of software or hardware packages needed for the project. P rototyp e with evaluation licenses from the vendors to take care of both critical path and back up technologies. From the management point of view, rational decision making is a must as part of the selection process in object technology to identify Boat Anchors before purchasing such packages.

4.6 Golden Hammer General Form A software development team has gained a high level of competence in a particular solution or vendor product, referred to here as the Golden Hammer. As a result, every new product or development effort is viewed as something that is best solved with it . In many cases, the Golden Hammer is a mismatch for the problem, but minimal effort is devoted to exploring alternative solutions Consequences Requirements are not fully met, in an attempt to leverage existing investment. Existing products dictate design and system architecture

4.6 Golden Hammer  New development relies heavily on a specific vendor product  System architecture is best described by a particular product, application suite, or vendor tool set.  Developers become isolated from the industry. They demonstrate a lack of knowledge and experience with alternative approaches Causes Several successes have used a particular approach Large investment has been made in training and/or gaining experience in a product or technology.

4.6 Golden Hammer Refactored Solution F rom the top to the bottom in an organisation, there must always be an awareness of technological development in the areas of their activity, the types of new tools or products which will best suit for the specific requirements, etc. T he management must have the commitment to expose and train the developers in the organisation towards this concept so that they are aware with new developments in technology Software systems need to be designed and developed with well-defined boundaries that facilitate the replaceability of individual software components (without affecting other components)

4.7 Dead End General Form I f the reusable components bought from a specific vendor are not maintained or supported by him When it is not be possible to modify them to a new environment , the project may meet the Dead End Improvements in the reusable component cannot be easily integrated, and support problems may be blamed on the modification Refactored Solution  Avoid COTS Customization and modifications to reusable software  When customization is unavoidable, use an isolation layer to separate dependencies from the majority of the application software from customizations and proprietary interfaces

4.8 Input Kludge General Form  Lack Consequences  Lack Causes  Lack Refactored Solution  Lack

4.9 Spaghetti Code General Form  Lack Consequences  Lack Causes  Lack Refactored Solution  Lack

4.9 Continuous Obsolescence General Form  Lack Consequences  Lack Causes  Lack Refactored Solution  Lack

4.10 Mushroom Management General Form  Lack Consequences  Lack Causes  Lack Refactored Solution  Lack

4.11 Poltergeists General Form  Lack Consequences  Lack Causes  Lack Refactored Solution  Lack

4.12 Walking through a Minefield General Form  Lack Consequences  Lack Causes  Lack Refactored Solution  Lack

4.13 Cut-And-Paste Programming General Form  Lack Consequences  Lack Causes  Lack Refactored Solution  Lack

6.Methodological Anti-Patterns

7.Conclusion AntiPatterns are normal Some AntiPatterns must be tolerated Accept those things you cannot change, have the courage to change those things you can, and the wisdom to know the difference. —Serenity Prayer  Avoid the use of the Golden Hammer excessive use of one pattern ( there are at least 192 software patterns … 23 GoF, 17 Buschmann, 72 analysis, 38 CORBA, 42 antipatterns  Consider a range of solutions

8. References “ AntiPatterns - Refactoring Software And Projects in Crisis ”, Brown, Malveau, Mowbray , 1998 http://en.wikipedia.org/wiki/Anti-pattern http://www.icmgworld.com/corp/news/Articles/RS/dec_0101.asp, Dr. R. Srinivasan( Chief Technology Officer, Internet Component Management Group, ) http://webhome.csc.uvic.ca/~hausi/480/lectures/antipatterns.pdf http://sourcemaking.com/antipatterns

9. Q&A ANY MORE QUESTİONS AFTER ALL THİS STUFF?? THANK YOU….

Anti-Patterns

More Related Content

What's hot

Similar to Anti-Patterns

Anti-Patterns

Editor's Notes