All you need is fast feedback loop, fast feedback loop, fast feedback loop is all you need

Join us in exploring the importance of having an agile feedback loop in software development.

By minimizing the time between code changes and receiving feedback, teams can accelerate bug detection, improve software quality, enhance collaboration, and increase happiness.

We'll discuss key components like continuous integration, automated testing, monitoring, and best practices and strategies. Discover the benefits of implementing DORA metrics, running experiments, using feature flags, and saving costs. Prepare to be inspired by real-life cases and understand how a fast feedback loop can revolutionize your development process.

Participants will be encouraged to adopt a "fast feedback loop" mentality, emphasizing the transformative impact it can have on the efficiency and effectiveness of software development and, at the end, be prepared to sing in chorus (emulating a famous band): "Fast feedback loop, fast feedback loop, fast feedback loop is all you need!" 😉

---
Presentation shared at WeAreDevelopers World Congress '24

Feedback form:
https://bit.ly/feedback-fast-feedkback-loop

1. All you need is fast feedback loop, fast feedback loop, 🎶 fast feedback loop is all you need 🎹 1 July, 2024 WeAreDevelopers World Congress

2. Nacho Cougil Principal Software Engineer at Dynatrace TDD & clean code fan Started to write in Java before Y2K Founder of the Barcelona Java Users Group ( BarcelonaJUG ) & co-founder of the Barcelona Developers Conference ( DevBcn ) former Java and JVM Barcelona Conference Java Champion Father , former mountain marathon runner 😅 @ icougil https:// jvm.social /@ icougil Who am I?

3. 3

4. 4

5. - We should isolate our environments to clearly identify functionalities that are not working - Let’s use new infrastructure and deploy everything from scratch every single time we push any changes -We have some flaky tests - Nah, just retrigger the build

6. -Ey, it is a bit complicated to show what we have built in every Sprint . What if we create some simulations with fresh data to demo much better all the functionalities? -Yes, sure! This is feasible and looks reasonable - How can be 100% sure that our service is working as expected with the all-external services? - Yes, let’s “froze” each service for every deployment, and run all the integration tests across all the services

7. -Ey, our customers are notifying us that we have some errors in our system. We must do end-to-end tests to verify the functionalities are working as expected! -Yes, of course! We must do it! -Let’s include it in our pipeline! -We are worried about the performance our system. Shoul d we include some load tests in our CI system? -Sure, why not?

8. 21 https:// xkcd.com /303/

9. We should strive for an efficient, simple and reliable mechanism for delivering changes

10. why ?

11. We are paid to deliver value to our customers Software that is used by customers is working as expected can be changed Reme mber

12. The agile manifesto https://agilemanifesto.org/

13. We must adapt to changes Adaptation = Agility Adapt to changes

14. Again, the ag ile manifesto https://agilemanifesto.org/

15. We must deliver {working} things We MUST iterate 🔁 fast  to save money 💰 & time ⏳  to make our developers happy 😊 { because we want to deliver more & faster features than our competitors } Ability to iterate

16. What’s the overall amount of time developers are waiting for local builds or PR’s builds to finish? Let’s do some maths

17. Netflix reduced a 62-minute test cycle time to just under 5 minutes (in just 1 app) It is about money https://gradle.com/blog/netflix-pursues-soft-devex-goals-with-hard-devprod-metrics-using-test-distribution/

18. Top 5 reasons for developers to be happy at work: salary (60%) work-life balance (58%) flexibility (52%) | productivity (52%) , and growth opportunities (49%) … but only money? ? https://stackoverflow.blog/2022/03/17/new-data-what-makes-developers-happy-at-work/

19. Top 3 reasons makes a future employer attractive: Developer experience (53%) Salary transparency (41%) Learn from others (40%) https://stackoverflow.blog/2021/12/07/new-data-what-developers-look-for-in-future-job-opportunities/ … but only money? ?

20. will make developers more efficient Improving the development process Interesting flow will make developers happier + quality + collaboration + productivity

21. how ?

22. Will our users understand this super cool feature, or will they get frustrated because is so complicated? You must learn by experimenting ( lean experimentation ) hypothesis build an experiment analyse the results act Try things! Run experiments ! !

23. Feature flags, for the win ! Technique that allows dis|enable of certain features or code paths in a product or service, without modifying the source code. A toggle allows to turn a feature on/off , and test it https://openfeature.dev

24. Deploy/release twice a month VS Deploy 6-7 times a day Up to a week to fix bugs VS Fix bugs in a day Use case: Paramount https://launchdarkly.com/blog/paramount-improves-developer-productivity-100x/

25. Minimize end-to-end tests to the minimum Less UI tests, more integration tests Decouple components Adopt contract testing Separate pipelines Benefits Faster build & deployments Improve team autonomy Less noise for developers  happier Better documentation Helps to improve the communication between teams Remove dependencies and bottlenecks

26. Move all the testing part earlier in the lifecycle  (i.e. move it left 👈 on the project timeline) ”Test early and often” Fail fast! Shift left 👈 !

27. Early defect detection Better predictability and planning Cost efficiency Improved quality Customer satisfaction Faster time to market Enhanced collaboration Some benefits https://www.sonarsource.com/blog/leveraging-sonarqube-sonarcloud-and-sonarlint-for-effective-shift-left-practices/

28. Automated testing & Continuous Integration Automate build Ease of integrating changes Faster delivery Enabling rapid feedback Easily detect bugs Improve software quality Increase collaboration Facilitates deployment automation

29. Etsy deploys more than 50 times a day Deploy on developer 1 st day  Engineers get productive faster The level of cooperation (developers, ops, etc) is higher Features are tested easier by the teams Use case: Etsy https://www.infoq.com/news/2014/03/etsy-deploy-50-times-a-day/ https://www.etsy.com/codeascraft/how-does-etsy-manage-development-and-operations

30. Use case: Hilti Deployment times have decreased from 3 hours to 15 minutes (12 x faster) Feedback loops have shortened from 6 days to 3 (50%) Number of code checks increased: from 6 times every 3 months to twice a week (400%) Higher quality https://about.gitlab.com/customers/hilti/

31. R eal-time monitoring of applications and infrastructure can help detect and resolve issues before they become problems . Benefits Increase application stability and uptime Faster issues resolution Reduce operational costs Improve developer and operational productivity Better customer experience Monitoring is also a must

32. Reduced the Mean Time To Detection (MTTD) from 6 hours to 15 minutes (96% lower) Faster delivery: t eams ship projects in weeks (instead of quarterly) New developers and contractors onboard in 3–4 days instead of 8–12 weeks (20x faster) Use case: Toyota https://www.datadoghq.com/case-studies/toyota/

33. 58% increase in (high-quality) software releases Major service incidents down 94% (over past 5 years) Ability to anticipate and resolve issues before impact Increased operational efficiencies  b etter collaboration across teams Use case: Bank of New Zealand https://www.dynatrace.com/customers/bnz/

34. DORA metrics Metrics can help you measure your team’s performance  identify areas for improvement Throughput Change lead time  Deployment frequency  Stability Change fail percentage  Failed deployment recovery time https://dora.dev/

35. Throughput Change lead time  - Time ⌛ it takes for a code commit or change to be successfully deployed to production. Deployment frequency  - How often 🔄 application changes are deployed to production. DORA metrics Stability Change fail percentage  - Percentage of deployments that cause failures in production, requiring hotfixes 🚨 or rollbacks. Failed deployment recovery time  - Time it takes to recover 📈 from a failed deployment. https://dora.dev/

36. "When a measure becomes a target, it ceases to be a good measure" https://en.wikipedia.org/wiki/Goodhart%27s_law Having one metric to rule them all Making disparate comparisons (ex: mobile app VS mainframe) Having siloed ownership ( devs , devops , etc) Do not compete! (the objective is to improve your team’s performance) Warn ing !

37. It will be enough?

38. monitoring C ontinuous integration Feature flags R emove dependencies Shift left Automated testing DORA metrics R un experiments Delete bottlenecks

39. Summary Practice/Strategy Benefits Run experiments Rapid learning and iterative development Feature flags Help in rolling out any new change for our users Remove dependencies Fostering team autonomy and better communication Delete bottlenecks Faster development & deployment process Shift left Flexibility and speed for fast feedback Automated Testing Reduce testing cost and time Continuous Integration Frequent integration & testing for rapid feedback on code quality Monitoring Visualise and better understanding how our systems behave DORA Metrics Quantifiable indicators for measuring and optimizing our development process

40. Summary Practice/Strategy Benefits Run experiments Rapid learning and iterative development Feature flags Help in rolling out any new change for our users Remove dependencies Fostering team autonomy and better communication Delete bottlenecks Faster development & deployment process Shift left Flexibility and speed for fast feedback Automated Testing Reduce testing cost and time Continuous Integration Frequent integration & testing for rapid feedback on code quality Monitoring Visualise and better understanding how our systems behave DORA Metrics Quantifiable indicators for measuring and optimizing our development process

41. 57

42. 58

43. 59

44. Questions? [email protected] https://nacho.cougil.com @ icougil https://jvm.social/@icougil