Slowdown to Grain Speed: Technical practices that take time but save time.
summary
Argues that intentionally slowing to do design, refactoring and tests saves time later, backed by concrete practices: run short prototypes (spike to learn) before writing production code, keep continuous refactoring, aim for measurable code coverage that often exposes design bugs (one unit test file was 750 lines), rotate reviewers to enable collective ownership, and build CI checks for automated verification. Gives a finance-team case where architect reframes local vs global time costs and an anecdote of automating a weekly PDF task in 20–40 minutes that eliminated repeated manual work.
AI-written summary · about
chapters (21)
- 0:00Introduction to slowdown
- 2:35Agile development misconceptions
- 7:20Feedback loops in Agile
- 13:07Adaptive planning importance
- 17:26Slowing down to gain speed
- 19:59Automated testing benefits
- 24:59Technical practices for quality
- 27:33Creating quality code
- 29:49Continuous refactoring
- 33:05Spike to learn approach
- 35:10Automated verification necessity
- 38:23Code coverage and design
- 41:12Code reviews and collaboration
- 42:13Collective code ownership
- 43:15Automate repetitive tasks
- 45:42Long-term speed over short-term
- 46:46Q&A session begins
- 51:25Handling production bugs
- 55:41Unit tests as continuous checks
- 57:04SLO and error budgets
- 58:07Closing remarks and support
related talks
29mEconomies of Speed
23mThe Cost of Speed: Rethinking "Move Fast" in DevOps
51mThe astonishing value of speed
45mAccelerating Software Delivery: Why Your Team Is Slowing Down
45mThe astonishing value of speed
32mTime Driven Development
22mOptimizing Product Development: Balancing Speed, Quality, and Process
27mDeveloper Experience: It’s Time to Start Complaining