How to win in software development with tighter feedback loops
summary
Engineering teams measure a Build Pain Index = median build time ÷ build success rate to justify tooling and cut developer wait time; a 300-commit week with 30 minute builds at 90% success costs ~900 lost minutes. Visual dashboards use Chartio and Honeycomb, logs and alerts in Datadog, and CI on EC2; parallelizing tests and horizontal scaling shards 1,000 tests into groups to drop wall time. Flaky tests go into quarantine, feature flags and traffic-splitting run bake-off experiments (Optimizely sees 500B–1T events/month) and Google ran ~9,800 experiments in 2016.
AI-written summary · about
chapters (25)
- 0:00Introduction and setup
- 1:28Talk overview and goals
- 2:55What is a feedback loop
- 4:18Challenges in software development
- 5:44Velocity across company stages
- 7:30DORA state of DevOps study
- 9:37Key metrics to track
- 11:43Cost of unstable builds
- 13:07Build Pain Index explained
- 15:37Visualizing metrics
- 17:25Automating feedback loops
- 18:28Efficient build strategies
- 19:51Inefficient feedback loops
- 20:57Code coverage tools
- 21:39GitHub and Slack integration
- 22:44Release notes automation
- 23:26Engineer-owned QA process
- 24:09Prioritizing test frameworks
- 24:51Test quarantine approach
- 26:16Experimenting with feedback
- 26:37Feature flags and rollouts
- 29:07De-risking backend changes
- 31:16Real-world Google examples
- 32:41Final thoughts and summary
- 34:52Q&A session
related talks
27mDeveloper Experience: It’s Time to Start Complaining
46mDeveloper Productivity at Scale
02h 31mDeveloper Productivity Engineering - Extended Session
58mDeveloper Joy – How Great Teams Get S%*t Done
52mSurviving the Techpocalypse with Developer Productivity Engineering
32mOn the Care and Feeding of Feedback Cycles
10mAchieving engineering velocity by optimising developer experience
45mAn Open Source Approach to Driving Developer Efficiency