The document discusses strategies for improving software development processes through rapid feedback loops, automated testing, and continuous integration. It emphasizes the importance of adopting agile principles, running experiments, and using feature flags to enhance team autonomy and communication. Various case studies highlight the benefits of these practices, including faster deployment times, improved quality, and increased developer satisfaction.

1. All you need is fast feedback
loop,
fast feedback loop, 🎶
fast feedback loop
is all you need 🎹
October, 2024

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

21. 2
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-dat
a-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-dat
a-what-developers-look-for-in-future-job-oppor
tunities/
… 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.d
ev

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-impr
oves-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-son
arqube-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-deplo
y-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/toyo
ta/

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
/bnz/

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. monitorin
g
Continuous
integration
Feature
flags
Remove
dependencie
s
Shift left
Automate
d testing
DORA
metrics
Run
experimen
ts
Delete
bottlenec
ks

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

57. 57

58. 58

59. 59

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