Designing software that maximizes developer productivity
summary
Argues that a modular monolith — splitting a Rails codebase into named components with strict public APIs and owned data — cuts coupling enough to restore developer productivity without full microservices. Implements it by labeling ~6000 Ruby classes, moving files in one Big Bang PR with automation, and building an in-house tool called wedge that builds a call graph, scores isolation, flags violations and enforces progress (50% targets). Work takes years but lets teams extract or replace subsystems (example: tax engine) and measurably reduce cross-domain churn.
AI-written summary · about
chapters (10)
- 0:00Introduction and context
- 1:14The monolithic architecture
- 3:24When to redesign
- 4:46Pain points in the monolith
- 5:58Ruling out microservices
- 7:20Moving to a modular monolith
- 8:36Reorganizing the codebase
- 10:47Isolating dependencies
- 12:20Enforcing future boundaries
- 14:16Evolution and conclusion
related talks
35mModularizing Rails Monoliths One Bite at a Time
46mClosing Keynote
34m"Taming your Rails monolith"
21mTaming Monoliths Without Microservices
33mRefactoring Towards Component-based Rails Architectures
35mWrangling Large Rails Codebases
39mTaming Monoliths Without Microservices
26mMonolith-ifying perfectly good microservices