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.

Hara-Kiri from Engineering (Best?) Practices :: Future.works 2020

Hara-Kiri from Engineering (Best?) Practices :: Future.works 2020

  • Be the first to comment

  • Be the first to like this

Hara-Kiri from Engineering (Best?) Practices :: Future.works 2020

  1. 1. HARA-KIRI FROM ENGINEERING (BEST?) PRACTICES Remote Tech Week April 27th to May 1st, 2020
  2. 2. Hello! I’M PEDRO TORRES I am a Director of Software Engineering at 12+ years experience giving Autonomy, Mastery, and Purpose to Engineering Teams 2
  3. 3. THE “BUILDING TRIFECTA” THAT DOOMS A COMPANY Building it the Wrong Way Building the Wrong Thing Building the Right Thing at the Wrong Time 3
  4. 4. 1. BUILDING THE WRONG THING Is one of the worst things that can happen to a company 4
  5. 5. 1. BUILDING THE WRONG THING Is one of the worst things that can happen to a company 5 https://www.boredpanda.com/failed-products-innovations-technology/?utm_source=google&utm_medium=organic&utm_campaign=organic
  6. 6. 2. THE RIGHT THING AT THE WRONG TIME It’s terrible since you have the right product at the wrong time 6
  7. 7. 2. THE RIGHT THING AT THE WRONG TIME It’s terrible since you have the right product at the wrong time 7https://www.forbes.com/sites/quora/2017/06/21/these-seven-startups-had-amazing-ideas-and-failed/ https://www.theverge.com/2020/4/13/21218908/amazon-fresh-whole-foods-delivery-waitlist-virtual-line-demand
  8. 8. 3. BUILDING IT THE WRONG WAY Can ruin a company too... and that is why I created this talk 8
  9. 9. 3. BUILDING IT THE WRONG WAY Can ruin a company too... and that is why I created this talk 9 https://www.bbc.com/pidgin/tori-52327936
  10. 10. WHAT WE’LL DISCUSS Tech Debt Bus Factor Mission Based Teams a.k.a. Squads Scalable and Resilient Systems Code Coverage Agility YAGNI Not Invented Here Syndrome Microservices Multiple Languages in your Stack Legacy Pull/Merge Requests Deploying Code on a Friday 10
  11. 11. TECH DEBT ○ Is a concept that reflects the implied cost of additional rework caused by choosing a quick (and easier) solution instead of using a better approach that would take longer. ○ As with monetary debt, if technical debt is not repaid, it can accumulate 'interest', making it harder to implement changes. 11
  12. 12. TECH DEBT 12 https://www.creditcardscanada.ca/education-centre/debt-issues/identifying-debt-warning-signs/
  13. 13. “Tech Debt shouldn’t pile up nor be fully paid. It should be managed. 13
  14. 14. BUS FACTOR ○ Is a measurement of the risk resulting from information and capabilities not being shared among team members, derived from the phrase "in case they get hit by a bus". ○ People must be both key and irreplaceable to contribute to the bus factor. 14
  15. 15. BUS FACTOR 15 https://knplabs.com/en/blog/process-lessons-learned-about-bus-factor-15-introduction
  16. 16. “Bus Factor should never be 1 but shouldn’t be huge too. It should be in the sweet spot. 16
  17. 17. MISSION BASED TEAMS A.K.A. SQUADS ○ Are small cross-functional, self-organized, usually with less than eight members. ○ The team members have end-to-end responsibilities, and they work together towards their long-term mission. ○ Conway's law: “Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure”. 17
  18. 18. MISSION BASED TEAMS A.K.A. SQUADS 18 https://www.pinterest.pt/pin/428686458281112519/
  19. 19. “Squads are a great concept but are a challenge in broad/deep architectures. The Squads’ depth is key for success 19
  20. 20. SCALABLE AND RESILIENT SYSTEMS ○ Highly available, scalable, and resilient systems are hard to create (and even harder to maintain). ○ Kubernetes (K8s) is a perfect example and an increasing trend. 20
  21. 21. SCALABLE AND RESILIENT SYSTEMS 21 https://docs.microsoft.com/en-us/azure/architecture/example-scenario/infrastructure/multi-tier-app-disaster-recovery
  22. 22. “It’s easy to get lost in resiliency, availability, and scalability work. Your systems should be dimensioned for your near future reality. 22
  23. 23. CODE COVERAGE ○ Code/Test coverage is a measure used to describe the degree to which the source code of a program is executed when a particular test suite runs. ○ A good practice is to aim to have around 80% coverage. 23
  24. 24. CODE COVERAGE 24 https://blog.laas.sh/step-16-100-code-coverage-for-all-e2e-tests-and-joi-integration/
  25. 25. “Code coverage is a great metric to keep track of. You can have 100% code coverage and still have bugs in your code. 25
  26. 26. AGILITY ○ Agile frameworks are very popular for software development. ○ Atlassian Jira is (probably) the most used software. 26
  27. 27. AGILITY 27 https://www.atlassian.com/blog/jira-software/introducing-jira-software
  28. 28. “Being Agile is not about (blindly) following a process. Agility is the ability to quickly gather and act upon feedback. 28
  29. 29. YAGNI ○ "You aren't gonna need it" (YAGNI) is a principle of extreme programming (XP) that states a programmer should not add functionality until deemed necessary. ○ On the other side of the spectrum, Gold Plating is the phenomenon of working on a project or task past the point of diminishing returns. 29
  30. 30. YAGNI 30 https://www.pinterest.pt/pin/484207397436128852/
  31. 31. “It’s easy to fall into the trap of adopting complex, oversized approaches. You should favor simple and elegant solutions with your near future in mind. 31
  32. 32. NOT INVENTED HERE SYNDROME ○ It’s the tendency towards “reinventing the wheel” (reimplementing something that is already available) based on the belief that in-house developments are inherently better suited than using existing implementations. ○ On top of it, the IKEA effect is a cognitive bias in which consumers engineers place a disproportionately high value on products they partially created. 32
  33. 33. NOT INVENTED HERE SYNDROME 33 https://medium.com/@zdiehlio/why-are-we-reinventing-the-wheel-c0f15bfae182
  34. 34. “It’s easy to find “flaws” in others’ solutions (you find what you look for). Using existing solutions (e.g. open source, SaaS) accelerates time to market. 34
  35. 35. MICROSERVICES ○ Microservices are a software development technique that arranges an application as a collection of loosely coupled services. ○ It’s a widely adopted approach leaving Monoliths behind 35
  36. 36. MICROSERVICES 36 https://medium.com/startlovingyourself/microservices-vs-monolithic-architecture-c8df91f16bb4
  37. 37. “Loosely coupled services are great to scale but not brilliant to start with. Make sure you know the effort and cost of using them right off the bat. 37
  38. 38. MULTIPLE LANGUAGES IN YOUR STACK ○ It’s tempting to adopt many in order to attract more talent and project an image of innovation and “cool” engineering culture. ○ Microservices unlocks this possibility. 38
  39. 39. MULTIPLE LANGUAGES IN YOUR STACK 39
  40. 40. “Adopting a new coding language shouldn’t be a light-hearted decision. Usually architecture solves problems not coding languages. 40
  41. 41. LEGACY ○ If you have Legacy is because you made it this far. ○ The moment you name a system “Legacy” no one will want to work on it. 41
  42. 42. LEGACY 42 https://www.linkedin.com/pulse/brand-new-legacy-code-developed-every-day-markku-kero/
  43. 43. “Remember that the code you write today is legacy tomorrow. “Legacy” is usually what pays our salaries. 43
  44. 44. PULL/MERGE REQUESTS ○ A Pull/Merge Request is a method of submitting contributions to an open development project. It occurs when a developer asks for changes to be considered for inclusion in a project’s main repository. ○ This means that no one can add code in the main project without having someone else (ideally a peer) “approving” it. 44
  45. 45. PULL/MERGE REQUESTS 45 https://www.atlassian.com/blog/bitbucket/5-pull-request-must-haves
  46. 46. “Pull/Merge Requests are great guardrails but it adds a step on your flow. It enables feedback and knowledge sharing if taken seriously. 46
  47. 47. DEPLOYING CODE ON A FRIDAY ○ Should you deploy right before a weekend? ○ There are strong opinions weakly held about this. 47
  48. 48. DEPLOYING CODE ON A FRIDAY 48 https://ih1.redbubble.net/image.680566333.5088/flat,750x,075,f-pad,750x1000,f8f8f8.jpg
  49. 49. “It is normal to be risk averse and avoid deploying code on certain occasions. You should strive to deploy at any moment, ideally multiple times a day. 49
  50. 50. WHAT WE DISCUSSED Tech Debt Bus Factor Mission Based Teams a.k.a. Squads Scalable and Resilient Systems Code Coverage Agility YAGNI Not Invented Here Syndrome Microservices Multiple Languages in your Stack Legacy Pull/Merge Requests Deploying Code on a Friday 50
  51. 51. ARE YOU BUILDING YOUR PRODUCT RIGHT? 51
  52. 52. THANKS! Any questions? You can easily find me on LinkedIn or Twitter by searching for ”Pedro Gustavo Torres” 52Remote Tech Week April 27th to May 1st, 2020
  53. 53. CREDITS Special thanks to all the people who made and released these awesome resources for free: ○ Presentation template by SlidesCarnival ○ Photographs by Unsplash 53

×