Learn 14 Antipatterns. Three types of antipatterns. Traps that are applicable to common solutions. Development, Architecture, and Project management pattern. Feud,Golder ,

1. LEARN ANTIPATTERNS
KARTHIKEYAN VK
@KARTHIK3030

2. WHY ANTIPATTERNS?
Common
defective
process
Industry
Vocabulary
Avoid Traps
Detailed
remedy
Define
refactoring

3. WHAT IS ANTIPATTERNS ?
• An anti-pattern is something that looks like a
good idea, but one backfires when applied.
• An Antipattern is a pattern that tells how we go
from a problem to a bad solution.
• Identifying bad practices can be as valuable as
identifying good practices.

4. DIFFERENT TYPES OF
ANTIPATTERN
Development Antipatterns Architecture Antipatterns
Project Management
Antipatterns

5. METHOD OF LEARNING
Actual Problem Common Solution Trap Effective Solution

6. DEVELOPMENT ANTIPATTERNS

7. DEVELOPMENT ANTIPATTERNS -
• Continuous Obsolescence
• Lava Flow
• Golden Hammer
• Walking through minefield
• Mushroom Management

8. CONTINUOUS OBSOLESCENCE
• Problem
• Support for particular version of
software is going to be withdrawn by a
vendor. Upgrade becomes mandatory
and urgent.

9. CONTINUOUS OBSOLESCENCE
• Counter Productive Solution
• Let us update our technology to next version

10. CONTINUOUS OBSOLESCENCE
• Trap
• Obsolescence means process of becoming
obsolete or outdated and no longer used, it
becomes continuous we just upgrade our
software.
• Wasting time on only upgrading the version of
software
• Version incompatibility occurs between
dependencies.

11. CONTINUOUS OBSOLESCENCE
• Effective solution
• Refactor/Rearchitect your application to
better architecture, so you can skip even the
upgrade of software version because your
system is robust.
• Proper abstraction will help in upgrading
easier, so abstract first before upgrading.

12. LAVA FLOW
• Problem
• MVP is approved, let us add some features to
the MVP and move it market.

13. LAVA FLOW
• Counter Productive Solution
• Add few features with the current
MVP and move it market to test the
waters with user environment,
without rearchitecting, because time
is money.

14. LAVA FLOW
• Trap
• Code will become like lava from volcano
with multiple if and else.
• More new features added on the brittle
MVP architecture.
• You keep adding small features to MVP,
by the time you know it becomes full
blown project.

15. LAVA FLOW
• Effective solution
• You need to build a architecture driven design
and replace your MVP application with a
project.
• Key is to think in terms of architecture driven
design from the start and should be ready to
ditch the MVP and move it to a project.

16. GOLDEN HAMMER
• Problem
• As an architect or developer, you learn a new
technology and you get excited by the
technology

17. GOLDEN HAMMER
• Counter Productive Solution
• Next problem that comes to you,
you start using the technology you
learnt and solve the problem.

18. GOLDEN HAMMER
• Trap
• You will be bending backwards, to fit your
solution into the problem.
• You will start seeing every problem as nail
and start using the learned or known solution
as Golden Hammer.

19. GOLDEN HAMMER
• Effective solution
• As a senior developer or an Architect, you
should always be skeptical about your choice
of solutions.
• Always ask yourself, Am I using your golden
hammer ?.
• Think of solutions/technology that exactly fits
your problem/challenge not your knowledge.

20. GOLDEN HAMMER
• Effective solution
• Always play Devils Advocate for your
choice.
• This does not mean you should be
insecure about your solution

21. WALKING THROUGH MINEFIELD
• Problem
• Follow Agile model in your project and deliver
project faster.

22. WALKING THROUGH MINEFIELD
• Counter Productive Solution
• Start implementing and release feature as fast
as possible.
• Reduce the time to market and acquire more
customer base.

23. WALKING THROUGH MINEFIELD
• Trap
• Build a brittle system that breaks every
day.
• Latest research tells us around 2-5 bugs
are being added for every line of code
added to the System.
• No proper test plan.

24. WALKING THROUGH MINEFIELD
• Trap
• Fix only symptoms, not the actual cause.
• Developers are not responsible for bugs,
testers are held responsible.

25. WALKING THROUGH MINEFIELD
• Effective solution
• Build a proper abstraction and architecture driven
design for scaling.
• Only, then implement feature faster, your
software build on strong base and enables
extension faster.
• Developer should feel ashamed when tester find a
bug in their code. Tester are only to validate
feature and do integration testing.

26. MUSHROOM MANAGEMENT
• Problem
• Don’t disturb developer, let them be productive.
• Overpowering manager wants to keep all his
control, because he is not tech savvy.

27. MUSHROOM MANAGEMENT
• Counter Productive Solution
• Hide them from stakeholders.
• Exclude them from all meetings
• Let requirements comes down from
multiple layers.

28. MUSHROOM MANAGEMENT
• Trap
• Keeping them in the dark, developers don’t know
what is happening with, what they are creating and
also what to create
• They grow like a mushroom in a dark room, and
managers manage them.

29. MUSHROOM MANAGEMENT
• Effective solution
• Let stakeholders talk to end-users,
let them be in the loop.
• If possible, make them travel to
onsite for 15 days at least and go to
actual place where the software is
used.

30. ARCHITECTURE ANTIPATTERNS

31. ARCHITECTURE ANTIPATTERNS
• Ad Hoc Integration
• Cover your assets
• Architecture by Implication
• Swiss Army Knife
• Reinvent the wheel

32. AD HOC INTEGRATION
• Problem
• Let us Integrate two different existing products
together, so they work seamless.

33. AD HOC INTEGRATION
• Counter Productive Solution
• Expose an interface and let the application talk to
each other in REST/TCP protocol.
• Integrate as fast as possible and move to
production and see how well, it is received in
market.

34. AD HOC INTEGRATION
• Trap
• No proper abstraction is Thought through.
• Hell goes loose because you cannot add features in
both the application because of brittle abstraction.
• This is like going back to Monolith to
Microservices.

35. AD HOC INTEGRATION
• Effective solution
• Take your time to build abstraction layer.
• Abstraction should be even outside the two
applications, like a Queue/Message
Mechanism based on project.
• Integration should be a new project, by itself.

36. COVER YOUR ASSETS
• Problem
• Document architecture of your application.

37. COVER YOUR ASSETS
• Counter Productive Solution
• Add every decisions in the document.
• Address all information in a single
view.
• Try to address all stakeholders in each
and every section.

38. COVER YOUR ASSETS
• Trap
• Document are unclear for communication with
stakeholders including developer.
• Too much information only makes the document
tough to maintain.
• Changes becomes hard because document is brittle
with unnecessary information relevant to present
architecture.

39. COVER YOUR ASSETS
• Effective solution
• Compare no more than 3 alternatives, to
record your decision process.
• Use Viewpoints to communicate to different
stakeholders.
• Find a document tool that helps to update
your document easily like Confluence
documentation or WIKI

40. ARCHITECTURE BY
IMPLICATION
• Problem
• From experience, architects understands
documentation process is burdensome.
• Understand the Cover your assets antipattern.

41. ARCHITECTURE BY
IMPLICATION
• Counter Productive Solution
• Architect solutions without
documentation.
• Follows architecture by implication and
discussion with developers

42. ARCHITECTURE BY
IMPLICATION
• Trap
• No proper thought process creates a brittle
software patterns.
• Scaling becomes a problems
• Missing the Process of putting your thoughts in a
document is more important than the actual
document.
• Discipline of playing a devils advocate for your own
choice of technology is missed.

43. ARCHITECTURE BY
IMPLICATION
• Effective solution
• Use Viewpoints to communicate to different
stakeholders.
• Find a document tool that helps to update
your document easily like Confluence
documentation or WIKI

44. SWISS ARMY KNIFE
• Problem
• Application should provide solutions to all
domain problems. E.g.:-Retail, Logistics etc

45. SWISS ARMY KNIFE
• Counter Productive Solution
• Build a single monolithic application
that solves all the problem.
• Put all your corresponding logic in a
single class file.
• Build all process in a single UI.

46. SWISS ARMY KNIFE
• Trap
• Violation of single responsibility principle.
• Violation of Interface segregation principle.
• Application becomes too complex for a change.

47. SWISS ARMY KNIFE
• Effective solution
• Think in terms of number lines you can put in
a class/method.
• How small is small in a module.
• Drive your solution based on event driven and
domain driven architecture.

48. REINVENT THE WHEEL
• Problem
• Members in the team with great developers and
architects, they are presented with a business
problem to solve.

49. REINVENT THE WHEEL
• Counter Productive Solution
• Start working on the problem and start
developing the solution.
• No R&D check to see whether the
solution is already solved in the market
and how it is solved.

50. REINVENT THE WHEEL
• Trap
• Always going for Build choice in Build Vs Buy
decisions
• Wasting solving the problems that may be already
solved.
• Burning midnight oil because the solution is built
ground up.
• Takes a long time to build a bug free solution.

51. REINVENT THE WHEEL
• Effective solution
• First research on the problem, whether it is
already solved
• Is there solution that is available in market.
• How much we can build and how much we can
buy ?

52. PROJECT MANAGEMENT
ANTIPATTERNS

53. PROJECT MANAGEMENT
ANTIPATTERNS
• Blowhard Jamboree
• Death by Planning
• Intellectual Violence
• The Feud
• Fire Drill

54. BLOWHARD JAMBOREE
• Problem
• Technology consultant are bought into the team
for consultancy for a particular technology or
domain challenge.
• Business stakeholders attends a new conference
or reads about new technology.

55. BLOWHARD JAMBOREE
• Counter Productive Solution
• Developers are bought into meeting
with the consultant and developers
need to explain their problem and
listen for solution.
• Developers answers the concerns of
stakeholder with respect to new
technology.

56. BLOWHARD JAMBOREE
• Trap
• Developers spend too much time answering the
concerns of managers and decision makers.
• Experts are misinformed; occasionally, they
represent biased viewpoints.
• Rarely is there any hands-on research and
experience backing up their conclusions.

57. BLOWHARD JAMBOREE
• Effective solution
• An in-house expert on each key technology is
an invaluable asset to every organization
• Give developers time to do POC and propose
solution in structured manners.
• Ask questions and incentivize innovative and
collaborative ideas.

58. INTELLECTUAL VIOLENCE
• Problem
• When someone who understands a theory,
technology, or buzzword uses his knowledge to
intimidate others in a meeting situation.

59. INTELLECTUAL VIOLENCE
• Counter Productive Solution
• Developers consult them as a final
step, if they cannot solve a problem.
• They put up with the ill-treatment
because they need them.
• Defensive culture

60. INTELLECTUAL VIOLENCE
• Trap
• Non-collaborative environment is created.
• Gangs formed.
• People are de-motivated when they want to learn
anything new. They feel they are good enough.

61. INTELLECTUAL VIOLENCE
• Effective solution
• Talk to the intimidator and tell him to become
a mentor rather than being antagonist
• Knowledge imbalance should be brought
down by proper training.
• Make sure intimidator does not feel insecure
about his position otherwise it will backfire.

62. THE FEUD
• Problem
• Conflicts between managers.

63. THE FEUD
• Counter Productive Solution
• Developers tend to take a calculated
risk when addressing concerns.
• Co-operation seems to be ambiguous
in presence and absence of the
manager.
• Emails are used extensively for every
communication.

64. THE FEUD
• Trap
• Waste of time.
• Unproductive environment.
• Hostile environment where co-operations between
teams are punished directly or indirectly.

65. THE FEUD
• Effective solution
• More office gatherings.
• Effective plan to tear down the wall by the
higher management.
• Facilitate new relationship formation.
• If nothing works, separate them.

66. FIRE DRILL
• Problem
• Project is started and not much of the decisions
are finalized.

67. FIRE DRILL
• Counter Productive Solution
• Management asks the developers to
wait.

68. FIRE DRILL
• Trap
• Waste of time.
• Compromises are willingly made in software quality
and testing.
• In a perverse way, the emergency situation makes
the job easier for some software developers, as
management will accept almost any software.

69. FIRE DRILL
• Effective solution
• Use internal and external models technique.
• Internal models will be almost concrete, so
start working on them until external models
are finalized.
• Start the project after a certain stage of initial
discussion and then demo to stakeholders so
they can think by looking rather than thinking
in paper.

70. SUMMARY
• Antipatterns helps to avoid the common
solution traps
• Three types of antipatterns
• Antipatterns improves your vocabulary.
• Think of antipatterns as checklist when
taking up known solutions and the
problem that comes with it.

71. REFERENCES
• https://wiki.c2.com/?AntiPattern
• https://sourcemaking.com/antipatterns