Engineering Anti-Patterns @JQueryTO 2014
3 likes1,076 views
This document discusses various anti-patterns that can occur in software engineering projects and how to overcome them. It describes three main anti-patterns: analysis paralysis, where too much time is spent analyzing instead of taking action; design by committee, where too many designers are involved without clear leadership or vision; and reinventing the square wheel, where existing solutions are ignored in favor of custom solutions. It then discusses how adopting principles of mastery, autonomy and purpose at an organization can help overcome anti-patterns by promoting continual learning, self-directed work, and alignment with organizational goals.
Engineering Anti-Patterns @JQueryTO 2014
- 1. nahim nasserVP of Engineering @BNOTIONS @NAHIMNASSER
- 4. Repeated patterns that result in negative consequences
- 5. Repeated patterns that result in negative consequences When solutions exist
- 6. 84%Of ALL software projects fail
- 10. Hope you weren’t apart of this one
- 11. Not to be confused with Test Driven Development
- 12. Ouch.
- 13. Whats wrong with that? Haha…
- 14. Key takeaways
- 15. anti patterns are bad
- 16. it is good to be able to recognize them anti patterns are bad
- 17. it is good to be able to recognize them It’s even better to know what to do when you find them anti patterns are bad
- 18. it is good to be able to recognize them overcoming anti-patterns unlocks incredible potential in your organization anti patterns are bad It’s even better to know what to do when you find them
- 22. Analyzing for too long, while the opportunity passes
- 25. Convergence in language features, fragmentation in the number of languages
- 28. Comparsion MAtrices TODO APPS Community Research hiring market research
- 29. Comparsion MAtrices TODO APPS Community Research COST-benefit Analysis hiring market research Tradeoff analysis
- 30. Comparsion MAtrices TODO APPS Community Research COST-benefit Analysis hiring market research Tradeoff analysis EASY TO GET TRAPPED
- 31. 0 25 50 75 100 Opportunity Cost Benefits analysis paralysis
- 32. 0 25 50 75 100 Opportunity Cost Benefits analysis paralysis
- 34. Agile was designed to attack analysis paralysis to handle changing business requirements
- 36. everyone started applying this to business requirements
- 37. what if we applied this to our technology stack?
- 38. What if we accounted for incremental renovation right from the start?
- 41. platform agnostic framework Agnostic Language agnostic
- 43. SIDE EFFECTS
- 44. birth of the ‘polyglot' programmers
- 45. technology choice agility is also a great motivator for engineers
- 50. too many software designers
- 51. No unifying plan or vision too many software designers
- 53. erwin edge-case
- 54. not bad to have a few designers, but unification is critical
- 55. Your app might work
- 56. ok now lets create some new features
- 57. vomit
- 58. more vomit Insult to injury
- 59. “It is better to have a system omit certain anomalous features… than to have one that contains many good but independent and uncoordinated ideas.” -Frederick brooks (mmm)
- 60. recommended solution: Designated design leader !
- 61. Designated design leader ! reform meeting processes recommended solution:
- 62. Designated design leader ! reform meeting processes explicit roles and outcomes recommended solution:
- 63. “…conceptual integrity is the most important consideration in system design. “ -Frederick brooks (mmm)
- 66. Failing to adopt an existing solution
- 67. Failing to adopt an existing solution and instead adopting a custom solution
- 68. which performs much worse than the existing one
- 69. “Hey, there’s this great library that does exactly what you need” -you
- 70. “That library will take a while to learn, and i can write it better myself faster” -Ricky Rewrite
- 73. Recommended solution: period of library mining !
- 75. lean towards battle-tested solutions libraries that have been tried, tested, and have traction.
- 79. impact how effective you are as an engineer Antipatterns
- 81. mastery
- 82. mastery Autonomy
- 85. manifestation: mastery internal education Technology choice Agility challenging work
- 86. Autonomy
- 87. Autonomy acting with choice and influence
- 88. manifestation: autonomy self-directed teams teams choose what they work on teams choose who they work with teams choose how they build projects
- 91. manifestation: purpose constant alignment with the organization’s vision
- 93. mastery
- 94. mastery Autonomy
- 96. positive effect on business outcomes
- 97. positive effect on personal happiness
- 98. positive effect on ‘work’ engagement
- 100. anti-patterns design patterns well rounded leadership
- 101. @NAHIMNASSER @BNOTIONS email me your stories: nahim@bnotions.com