Many More Much Smaller Steps
I am far more concerned with changing the world right now than I am with changing code. I hope you are, too.
Premises
- Actual change […] happens in an incredibly twisty, complicated, loopy, ever-shifting high-dimensional, murky, and curved manifold, one we call “reality”.
- Directed parallelism — where a central intelligence plans, monitors, and coordinates multiple streams of activity — has a sharply rising non-linear cost curve, at even very small numbers of streams.
- Small steps have intrinsic value in human enterprises. Benefits of small steps are steerability, interruptability, grokkability, rhythm, motivation, focus, reversability, and undirected target parallelism.
- Embracing change, in technique and attitude, is increasingly well understood, and the costs of avoiding change are extremely high.
Steps and Actions
It’s the nature of the steps that is making the path look this way, their constraints. Each step meets a minimum of three criteria. 1) It must be small enough. 2) It must be shippable on completion. 3) It must not make things worse.
The system starts ready, and it ends ready, and the step is that period during which it’s not ready.
A step can be one action or many, but to be a step it has to take us from ready to ready.
A step has to bee a) small enough, and b) not make things worse.
A) Steps Should Be Small Enough
Step size depends on operational context
- changing production-ready code: That is, each step we’re taking has the actions of checking out the code, editing it, and checking it back in. My stride-length here is “well under an hour.”
- changing product, in which we are implementing a story. My standard stride-length for this is less than 2 team-days from start to finish.
Maybe the biggest lesson I learned from TDD back in the oughties was just how far I could reduce my stride-length if I only chose to. Making that choice made me a far stronger — and faster — programmer.