Circles of Hell in Software at Scale
What happens to the baby while you're at the beach
Kartik Agaram
(
Slides
presented at
Refactor Camp, March 2013.
Notes.)
How we view programming
Plans, Prioritization
Problems and automated solutions
Stay lean, iterate fast, fail fast
…
Language of a static world
Reality: problems recur under pressure
Startup: What should we build? Why is this so slow?
OMG, something broke!
BigCo: What should we build? Why is this so slow?
OMG, something broke!
Meanwhile, more programmers, more users, traffic, attention …
A refactored view: circles of hell
A refactored view: circles of hell
- Deploying to production
- Automated testcases
A refactored view: circles of hell
- Deploying to production
- Automated testcases
- Enumerating assumptions
A refactored view: circles of hell
- Deploying to production
- Automated testcases
- Enumerating assumptions
- Switching architectures
A refactored view: circles of hell
- Deploying to production
- Automated testcases
- Enumerating assumptions
- Switching architectures
- Detecting over-engineering
A refactored view: circles of hell
- Deploying to production
- Automated testcases
- Enumerating assumptions
- Switching architectures
- Detecting over-engineering
- Preventing capture
Circles of hell aren't just sub-problems
Dynamic equilibrium
Too slow to solve next problem → previous problem comes back, but worse.
Just one possible path; may be others
But these are recurring pain points
Non-solutions
Most rules → ossification
Putting engineers in charge
Metrics → capture
What's left?
Hire less
Metrics: no splitting; Satisficing > Optimizing
Foster ownership
Keep things easy to change
Help newcomers see the big picture
Beware 'abstractions'
Welcome outsiders but control externalities