The document emphasizes the importance of fast feedback loops and efficient development processes for delivering high-quality software to customers. It suggests methods like automated testing, continuous integration, feature flags, and monitoring to enhance team performance and streamline the development lifecycle. Additionally, it discusses the significance of using metrics like DORA to measure and improve team efficiency and adaptability in development practices.

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 😅
Who am I?

3. 3

4. 4

15. - 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

16. -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

17. -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.
Should we include some load
tests in our CI system?
-Sure, why not?

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

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

25. why ?

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

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

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

29. Again, the agile manifesto
https://agilemanifesto.org/

30. 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

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

32. 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/

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

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

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

36. how ?

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

38. 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

39. 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/

41. 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

42. 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 👈 !

43. 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/

44. 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

45. • Etsy deploys more than 50 times a
day
• Deploy on developer 1st 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

46. 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/

47. Real-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

48. • Reduced the Mean Time To
Detection (MTTD) from 6 hours to
15 minutes (96% lower)
• Faster delivery: teams 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/

49. • 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
 better collaboration across
teams
Use case: Bank of New
Zealand
https://www.dynatrace.com/customers/bn
z/

50. 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/

51. • 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/

52. "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)
Warning !

53. It will be enough?

54. monitoring
Continuous
integration
Feature
flags
Remove
dependencie
s
Shift left
Automated
testing
DORA
metrics
Run
experiment
s
Delete
bottleneck
s

55. 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

56. 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

58. 58

59. 59

60. Questions?
nacho@cougil.com
https://nacho.cougil.com
@icougil
https://jvm.social/@icougil