Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Anti-Patterns part 1


Published on

Part 1 of Anti-Patterns webinar by Dmitry Kochergin

Published in: Education, Technology
  • Be the first to comment

Anti-Patterns part 1

  1. 1. Anti-patterns part 1Dmitriy Kochergin, DeveloperDnepropetrovsk, 2012August 6, 2012
  2. 2. Content• Root causes of anti-patterns• Organizational anti-patterns• Project management anti-patterns• Software design anti-patterns• Object-oriented design anti-patterns 2 2
  3. 3. Goals• Learn common anti-patterns – their symptoms – and solutions• Have no fear to admit your mistakes• Will to improve your skills 3 3
  4. 4. Anti-patternAnti-pattern is a pattern that may be commonlyused but is ineffective and/or counterproductivein practice Wikipedia “Something that looks like a good idea, but which backfires badly when applied” Jim Coplien “Commonly reinvented bad solutions to problems” 4 4
  5. 5. Anti-pattern• 5/6 of software projects are regarded as failures• 1/3 of software projects are canceled• 2/3 of software projects are twice the expectedbudget and take twice as long as originally planned 5 5
  6. 6. Why to learn Anti-patterns?• Why do we need to learn them? • real world examples of recurring problems with provided remedy • common vocabulary • developed to complement the existing fundamental software patterns (GoF, Buschmann, Analysis, CORBA) • helps to see the problem before they become a problem. • increase likelihood of project success • advance in your career • have more fun at work 6 6
  7. 7. Pattern Antipattern7 7
  8. 8. Patterns and anti-patterns8 8
  9. 9. Part 1 Root causes of anti-patterns9 9
  10. 10. Root Cause of Anti-Patterns: Haste• Haste – aggressive project deadlines and budget – lower acceptance levels for code quality – insufficient testing – patches – accumulating technical debt 10 10
  11. 11. Root Cause of Anti-Patterns: Apathy• Apathy: unwilling to find the proper solution; general lack of concern or care about solving a problem 11 11
  12. 12. Root Cause of Anti-Patterns: Narrow-Mindedness• Narrow mindedness: refusal to practice solutions that are otherwise widely known to be effective 12 12
  13. 13. Root Cause of Anti-Patterns: Sloth• Sloth: Poor decisions based upon an “easy answer” 13 13
  14. 14. Root Cause of Anti-Patterns: Avarice• Avarice: modeling of excessive/insufficient abstraction adding accidental complexity 14 14
  15. 15. Root Cause of Anti-Patterns: Ignorance• Ignorance: failure to seek a clear understanding of the problem or solution space (both intentional and non-intentional) 15 15
  16. 16. Root Cause of Anti-Patterns: Ignorance16 16
  17. 17. Root Cause of Anti-Patterns: Pride• Pride: The sin of pride is the Not−Invented−Here syndrome 17 17
  18. 18. Part 2 Organizational anti-patterns18 18
  19. 19. Analysis paralysis• Analysis paralysis: over-analyzing (or over- thinking) a situation, so that a decision or action is never taken, in effect paralyzing the outcome.• In software development it is exceedingly long phases of project planning, requirements gathering, program design and data modeling, with little or no extra value created by those steps. 19 19
  20. 20. Analysis paralysis• Reason: – treating task as over-complicated – fear of making false decisions – trying to find ideal solution• Solution: – try something and change if a major problem arises – process should not be bureaucratic• In contrast: extinct by instinct (making a fatal decision based on hasty judgment or a gut-reaction) 20 20
  21. 21. Design by committee• Design by committee: The result of having many contributors to a design, but no unifying vision• Reason: • poor architect leadership • programmers ego • lack of knowledge • lack of code conventions • lack of knowledge of code conventions • lack of auto checking of code conventions• «Camel is a horse designed by committee» 21 21
  22. 22. Design by committee• Results in: • internal inconsistency • needless complexity • logical errors • lack of a unifying vision • units that fit together poorly• Reuse is about people and education, not just architecture • know that it exists • know how to use it • are convinced that it‟s better than doing it themselves 22 22
  23. 23. Escalation of commitment• Escalation of commitment: The phenomenon where people justify increased investment in a decision, based on the cumulative prior investment, despite new evidence suggesting that the cost, starting today, of continuing the decision outweighs the expected benefit.• Examples: • bidding wars • staying in a hand in poker • trying to revive inevitably dying project 23 23
  24. 24. Vendor lock-in• Vendor lock-in: Makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs• Examples: • SIM locking • gift certificates • ICQ • Sony Memory Stick • external service or framework 24 24
  25. 25. Vendor lock-in• Result in loss of control: • feature you need is always 6 month away • vendor may change the product and brake your software• May result in antitrust action against a monopoly• Solution: Isolation layer 25 25
  26. 26. Other organizational anti- patterns• Cash cow: A profitable legacy product that often leads to complacency about new products• Management by perkele: Authoritarian style of management with no tolerance of dissent• Mushroom Management: companys staff being treated like mushrooms: kept in the dark, covered with dung, and, when grown big enough, canned (fired).• Bystander apathy: When a requirement or design decision is wrong, but the people who notice this do nothing because it affects a larger number of people 26 26
  27. 27. Part 3Project management anti-patterns27 27
  28. 28. Death march• Death march: Everyone knows that the project is going to be a disaster – so the truth is hidden to prevent immediate cancellation of the project• Project is artificially kept alive until the Day Zero finally comes ("Big Bang")• Alternative definition: Employees are pressured to work late nights and weekends on a project with an unreasonable deadline 28 28
  29. 29. Death march• Solution: • train senior and project management • policy for monitoring and controlling projects • manage risks and issues • provide appropriate resources • constrain project scope 29 29
  30. 30. Hero Mode• Hero Mode: the organization relies on the heroic efforts of a small number of capable individuals to achieve a successful outcome• Solution: • estimate properly • maintain and monitor a plan • distribute tasks • don‟t reward heroic behavior 30 30
  31. 31. Seagull manager• “Seagull managers fly in, make a lot of noise, dump on everyone, then fly out.” (Ken Blanchards 1985 “Leadership and the One Minute Manager book”)• Seagull manager interacts with employees only when a problem arises, making hasty decisions about things they have little understanding of, then leaving others to deal with the mess they leave behind 31 31
  32. 32. Give Me Estimates Now• Give Me Estimates Now: Senior Management wants estimates at very short notice, forcing the project to estimate with insufficient supporting data• Solution: • educate management • record estimates and actuals 32 32
  33. 33. Jekyll & Hyde Mr. Jekyll in private conversation, 8:01 AM: (gentle voice) “Yes, I think your idea is great, let’s talk it over in the lunch. It’s on me.” Mr. Hyde in project meeting with the subordinates and the big boss is listening, 8.03 AM (furious): “What the.. That’s a poor idea. And why no one has done anything to think about this beforehand? I can’t stand this kind of incompetence!”• Problem: A (typically opportunist) person whose behaviour is totally dependent on the audience. Jekyll transforms to and from Hyde in a nanosecond• Refactored solution: a good long talk in a proper and non- offending environment (pizza?); a transfer to other projects & departments 33
  34. 34. Lonely Rider “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• Refactored solution: interaction between developers, constant peer reviews, competence transfer, mentoring help to less experienced and busy developers 34
  35. 35. Metric Abuse• Metric Abuse: a malicious or ignorant misuse of measurement data, either to influence people or make management decisions• For example, code coverage• Solution: • collect metrics that relate to business goals • ensure measures have clear meaning 35 35
  36. 36. Other project management anti- patterns• Groupthink: During groupthink, members of the group avoid promoting viewpoints outside the comfort zone of consensus thinking• Overengineering: Spending resources making a project more robust and complex than is needed• Smoke and mirrors: Demonstrating unimplemented functions as if they were already implemented 36 36
  37. 37. Part 4 Software design anti-patterns37 37
  38. 38. Software bloat• Software bloat: Successive versions of a system demand more and more resources.• Reason: increasing proportion of unnecessary features• Results: program use more system resources than necessary, while offering little or no benefit to its users• Example: • Windows • Delphi programs 38 38
  39. 39. Software bloat• Solution: • use plug-ins, extensions or add-ons • use Unix philosophy: "Write programs that do one thing and do it well“• Similar anti-patterns • functions for tick • feature creep - extra features go beyond the basic function of the product and so can result in over-complication • code bloat • spaghetti code • unused functions • recalculation rather reuse already calculated value • copy-paste rather than reuse subroutine 39 39
  40. 40. Patterns Fetish• Patterns Fetish: Unreasonable and excessive use of design patterns• Designer looks for places to use patterns• Solution: • look at the design problem • favor simple solutions 40 40
  41. 41. Abstraction inversion• Abstraction inversion: Not exposing implemented functionality required by users, so that they re- implement it using higher level functions• This is not complex modules with simple interface• Results: • copy-pasting of internal implementation is error-prone and may corrupt with new version of external module • manual reimplementation may cost • user is forced to obscure his implementation with complex details of external module • user may patch framework and be bound to patched version 41 41
  42. 42. Big ball of mud• A big ball of mud is a software system that lacks a perceivable architecture.• Such systems are common in practice due to business pressures and developers rotation.• Symptoms • day-to-day patching the holes • maintenance nightmare 42 42
  43. 43. Gold plating• Gold plating: Continuing to work on a task or project well past the point at which extra effort is adding value.• The customer might be disappointed with the result, and the extra effort by the developer might be futile. 43 43
  44. 44. Other design anti-patterns• Input kludge: Failing to specify and implement the handling of possibly invalid input• Stovepipe system: a system that has the potential to share data or functionality with other systems but which does not. 44 44
  45. 45. Part 4 Object-oriented design anti-patterns45 45
  46. 46. Anemic domain model• Anemic domain model: business logic is implemented outside the domain objects• This pattern is a common approach in enterprise Java applications (possibly encouraged by technologies such as early versions of EJBs Entity Beans)• Anemic domain model is the typical result of not applying the GRASP information expert principle, i.e. you can avoid an anemic domain model by trying to assign responsibilities to the same classes that contain the data 46 46
  47. 47. Anemic domain model• Benefits • clear separation between logic and data • supports the Single responsibility principle by dividing the business data (changes very seldom) from business logic (changes often) • GRASP Pure Fabrication pattern: it‟s a class that doesn‟t represent a concept in the problem domain, specially made up to achieve low coupling, high cohesion. This kind of class is called "Service" in Domain-driven design 47 47
  48. 48. Anemic domain model• Liabilities • not truly object-oriented way • violation of the encapsulation and information hiding principles. • domain models objects cannot guarantee their correctness at any moment, because their validation and mutation logic is placed somewhere outside • increased coupling • code duplication, reduced code reuse • need of service layer when sharing domain logic 48 48
  49. 49. BaseBean• BaseBean is a utility object from which concrete entities are derived (via subclassing)• Class should not inherit from another class simply because the parent class contains functionality needed in the subclass• Derived class to rely on the internals of a base class which may be out of the control of the developer• Instead, delegation (has-a relationship) should be used• This is composition over inheritance case. 49 49
  50. 50. Call super• Call super: user which overrides a method required to call back the overridden function at a particular point.• The overridden method may be intentionally incomplete, and reliant on the overriding method to augment its functionality in a prescribed manner.• The language itself may not be able to enforce all conditions prescribed on this call is what makes this an anti-pattern• Note that it is the requirement of calling the parent that is the anti-pattern.• Use the Template method pattern instead 50 50
  51. 51. Circle-ellipse problem• Circle-ellipse problem (sometimes known as the square-rectangle problem) : This problem arises as a violation of Liskov substitution principle (This is the L in the acronym S.O.L.I.D. )• Liskovs principle: if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering the clients. 51 51
  52. 52. Circle-ellipse problem• Liskovs principle imposes some standard requirements on signatures • Contravariance of method arguments in the subtype. • Covariance of return types in the subtype. • No new exceptions should be thrown by methods of the subtype, except where those exceptions are themselves subtypes of exceptions thrown by the methods of the supertype.• Additionally subtype must meet behavioral conditions: • preconditions cannot be strengthened in a subtype. • postconditions cannot be weakened in a subtype. • invariants of the supertype must be preserved in a subtype. 52 52
  53. 53. Circular dependency• Circular dependency: relation between two or more modules which either directly or indirectly depend on each other• Problems: • tight coupling • can cause a domino effect when a small local change in one module spreads into other modules and has unwanted global effects • unclear modules‟ structure 53 53
  54. 54. Circular dependency• Follow Acyclic Dependencies Principle (ADP): The dependency structure between packages must be a Directed Acyclic Graph (DAG)• To break cycles: • use Dependency Inversion Principle (DIP) • create a new package that both packages depend upon 54 54
  55. 55. Constant interface• Constant interface: pattern describes the use of an interface solely to define constants, and having classes implement that interface in order to achieve convenient syntactic access to those constants.• Bloch, Joshua, Effective Java, 2nd Edition, p. 98• Problems: • it pollutes the class namespace with read-only variables that may not be of use • not clear where constant comes from without IDE • its not part of implementing class API (purpose of interface is to extend that API) 55 55
  56. 56. Constant interface• Alternatives: • convert the constants interface to a proper class with no instances • use Java 5 static imports 56 56
  57. 57. Monster object• Monster object (or God object, or Blob) is an object that knows too much or does too much: • doesn„t follow SRP • hard to maintain • hard to refactor • global variables • testability problems 57 57
  58. 58. Monster object• Be very suspicious of an abstraction whose name contains Driver, Manager, System, or Subsystem• Every class should have only one purpose, which can be described by few words• Use a roles and responsibility model• This technique is occasionally used for tight programming environments (such as microcontrollers, mobile phones) 58 58
  59. 59. Object cesspool• Object cesspool: when using object pools state of the objects returned to the pool should be reset• The pool is responsible for resetting the objects, not the clients• Reusing stale objects can cause bugs, security issues, personal information leaks. 59 59
  60. 60. Sequential coupling• Sequential coupling refers to a class that requires its methods to be called in a particular sequence• Methods whose name starts with Init, Begin, Start, etc. may indicate sequential coupling• Client is required to know too much about the class which methods have predefined execution order. It‟s also error-prone.• Sequential coupling can be refactored with the Template method pattern 60 60
  61. 61. Yo-yo problem• Yo-yo problem: occurs in a program whose inheritance graph is so long and complicated• Programmer has to keep flipping between many different class definitions in order to follow the control flow of the program• More generally, the yo-yo problem can also refer to any situation where a person must keep flipping between different sources 61 61
  62. 62. Yo-yo problem• Solution: • Keep the inheritance graph as shallow as possible • Use of composition instead of inheritance is also strongly preferred, although this still requires that a programmer keep multiple class definitions in mind at once • Hrair limit: The Magical Number Seven, Plus or Minus Two • meaningful method names 62 62
  63. 63. THANKS FOR COMING!!!• My contacts: – e-mail: – Skype: dmitry.kochergin 63 63
  64. 64. Questions Questions?64 64