Let’s talk about steps, a topic that’s relevant to my geekery interests, and maybe even a little relevant to the world outside of geekery today.
(I feel weird writing right now. I am going to do it anyway, primarily because, like most long-term sufferers from illness, I live in mortal fear of relapse, and part of my remission seems based on finding my topic & voice in writing.)
Don’t think that, by writing on geekery right now, that I’m trying to look away or evade my — our — responsibility in creating and maintaining this awful culture.
Stay safe.
Stay strong.
Stay kind.
Stay angry.
Black lives matter.
A lot of folks spend a great deal of time arguing about which step is the right step. A change-harvester would say to stop worrying about this so much.
The right step to take is 1) small, 2) not definitely backwards, and 3) not the last one.
Let’s take up "not the last one". A lot of thinking about change comes with the baked-in idea that there will be an end to it, a "finish line", if you will. We will make a change, or some changes, and in so doing we will cross a finish line, after which change stops.
This finish-line metaphor — I’m tempted to call it a theology — provides a great deal of fuel to the "right step" arguments. It’s so deeply embedded in our thinking it often goes quite unseen: it’s a premise at the bottom of huge towers of reasoning.
How it works: we first specify a finish line in considerable detail. I say line, but if we move our discussion to the N-dimensional space a team operates in, it collapses conveniently into a point. The arguments begin here.
The finish line is a faraway place, a "city on the hill", and almost the first thing we do is argue about stuff like "what color the walls will be painted". This takes a long while in and of itself, but we eventually emerge with a more-or-less rigorous description.
Now the finish-line kicks in to high gear, slipping insensibly into the metaphor of a footrace. We try to draw a straight line from where we are to the finish line, and we try to run along that straight line, seeking always to get to the finish line as "efficiently" as possible.
This path to the finish line is often drawn quite explicitly, across a two-dimensional representation of the space of time & possibility in our team and its artifacts, across "making-space". We slide, again often insensibly, into the world of maps and routes.
Three beliefs slip into our logic at this point: 1) that fewer and larger steps will get us their faster, and 2) that the only good steps are steps lying directly on that line, and 3) that the only good steps are steps directly implementing some aspect of the finish line.
The interplay of those three ideas creates a phenomenal amount of waste. It’s classic tragedy, really: to avoid an ill — inefficiency — we adopt a set of beliefs and practices that most normally result in us dramatically increasing the amount of that ill.
Notice all of this is based on the idea of finish line, the idea there will be a "last" change, beyond which there will be no further changes. None of those three ideas can exist without that premise.
Is the finish-line premise valid? You’re gonna hate me for this: it depends.
Let’s start with a trivial case where it’s not valid, one I think few of you will challenge.
It’s not valid if the finish line is five years away.
Across five years of software development, that abstract two-dimensional idealized straight line from here to the finish line is complete and utter nonsense in every respect. So any arguments we base on it are, at the very least, highly suspect.
At the scale of five years, there can and will be tens of thousands of changes in the "making space" we plotted our straight line on. And every one of those changes potentially forces us to re-draw that line.
- The personnel will change, as individuals and as a collective.
- The technology will change.
- The market will change.
- The competition will change.
- The finish-line itself will change.
And all of these are critically important to the making-space.
Okay, we took a trivially invalid case, let’s take a trivially valid one.
Is the finish-line premise valid if the finish-line is only five minutes away?
Well. Uh. Sure. I’m not even going to bother to work it out for you. Just, sure.
What if the finish line is between five minutes and five years? It’s our old friend the knee-shaped curve. I won’t rehash all that for now, but in one sentence: if we plot the validity of the premise against the distance to the finish line, that’s not a straight line.
That plot, from validity to distance, slowly degrades for a little while as we increase the distance, but then it suddenly dives, far faster than any increase in distance. Quite rapidly, beyond that knee, the validity of the premise becomes essentially nil.
Our arguments about efficiency, thoroughly based in finish-line reasoning, become invalid almost exactly as fast abd as much as the finish-line premise itself becomes invalid. They disappear into thin air.
And this leaves us with a very difficult problem, the problem we were trying to solve with all that argument in the first place: how do we decide which step is the "right step"?
The change-harvester says, first, the right step is small. This is because of that knee-shaped curve. (It’s also because small steps have intrinsic value to us. That’s a case I’ve made before and will make again, but not for today.)
And, because we go small with our size, we can’t get to the finish line we had in mind in one step. We’ll have to have many of these small steps. The overwhelming majority of those steps won’t be the last one.
(And again, there’s another case in here, spoken of before and not rehashed here: once you realize that most steps aren’t "the last step", you open up to the possibility that there is never a last step. Dynamic unities do stop changing eventually: on the day they die.)
And remember, the moment we give up the validity of the finish-line premise, we give up the plausibility of drawing a straight line in making-space from here to there. All our wrangling about whether a given step lies on that line or not becomes irrelevant.
And if we have to toss out the idea of having that staight line to the finish, we greatly reduce the value of worrying overmuch about whether a given step is on that line or part of the finish-line implementation.
And that leads us to "not definitely backwards". In change-harvesting, we call our approach "oriented". After each step, we turn to face our far-away finish line, we orient to it. Then we take another step. That’s enough, and it’s not just enough, it’s the best we can do.
Now, we’ve gone on a long ramble here, and I know I’ve missed spots by accident as well as on purpose. It’s a lot, this idea, and it runs very counter to standard practice & theory, so it feels like every element of it has to be explained again and again. I will keep trying.
But it’s real, and it’s serious. And I maintain that it’s applicable not just to changing code, but also to changing the world. The right step to take now is any step that is 1) small, 2) not definitely backwards, and 3) not the last one.
A million million years ago, the book that launched the extreme programming movement had a subtitle I’ve mentioned many times, and I’ll mention it again, now.
Embrace Change.
The GeePaw Podcast
If you love the GeePaw Podcast, show your support with a monthly donation to help keep the content flowing. Support GeePaw Here. You can also show your support by sending in voice messages to be included in the podcasts. These can be questions, comments, etc. Submit Voice Message Here.