Scaling Up!
summary
Argues that scaling software requires engineering to optimize for learning and low-coupling, not factory processes, and defines continuous delivery as keeping software releasable under an hour with development feedback under five minutes. Shows LMAX work: hundreds of commit-stage tests, about 35,000 commit-stage tests and ~20,000 acceptance tests plus performance suites that replayed the worst production hour at 5× load. Recommends modular, independently deployable services, JUnit/Selenium and DSL-based executable specs, and autonomous mission-led teams.
AI-written summary · about
chapters (24)
- 0:00Intro
- 4:03Learning
- 6:37Creative Discipline
- 10:36Continuous Delivery
- 13:29Deployment Pipeline
- 17:55Quality Efficiency
- 18:58Deployability
- 20:19Microservices
- 21:38Scaling
- 22:18Complexity
- 24:07Organization
- 29:32Autonomous Teams
- 31:56Setting Goals
- 32:19Job of the Team
- 32:43Autonomy
- 33:31Mission Based Planning
- 35:39Service Function
- 37:07Architecture
- 38:28Ensemble Programming
- 40:18Conclusion
- 40:40Questions
- 41:02Is the distributed approach really scalable
- 44:37How to make it possible
- 48:22Cycle of tests
related talks
28mFrom Startup to Scale Up: How to Scale Engineering teams
59mThe continuous culture
33mContinuous Delivery - What does good really look like?
33mSoftware development practices for companies that want to make an impact
19mScaling Fast – Engineering Lessons From ~15 Years of Tech Startups
26mScaling engineering organizations
30mMoving Fast At Scale- 19mScaling Fast – Engineering Lessons From ~15 Years of Tech Startups