The change-harvester uses these five words to describe the properties of successful change: human, local, oriented, taken, and iterative.
Let's talk about "local".
Let's talk about "local".
(If you want to see the previous one, about "human", check it out here:
These muses turn in to blogs + podcasts, and you can subscribe to them at geepawhill.org .)
These muses turn in to blogs + podcasts, and you can subscribe to them at geepawhill.org .)
When we say we want our changes to be local, we're talking about neighborhood, some rough concept of nearness, in multiple dimensions.
We want a proposed change to be "within reach". Remembering humanness, we want it to be something we can get our heads around. And we want it to be something we can really do. And we want it to be both doable today and done -- roughly -- tomorrow.
If we go with locality as something like neighborhood, we're saying in the neighborhood of our minds, in the neighborhood of our current situation, in the neighborhood of our ability, and in the neighborhood of now. That's what locality is about, nearness, and implicitly, size.
This notion, of locality, actually came to me from being a plain old code monkey, not a leader or teacher or coach or theorist, just a geek. The fact that it was so important in programming -- changing code -- helped me see how important it was in changing everything else.
I remarked once that the central skill of a working programmer is her ability to rapidly organize and re-organize mind-stuff. She does this by creating hierarchies of locality, then morphing them to new hierarchies of locality, and doing so change-by-change in a localized way.
My best days as a geek are days I move "green-to-green", in local steps of change, rearranging a little here, then a little there, then back, then to a third, in so doing creating massive transformation of a program's form and function. All done in the sense of local we mean.
Once I had these experiences, I came to two questions: 1) Can I get better at seeing the chain of local transformations that will yield the global one? 2) Can I use this same idea to make changes in things that aren't code?
The answer to both questions was -- it still is -- yes.
The answer to both questions was -- it still is -- yes.
In _Buckaroo Banzai_, during neuro-surgery, Buckaroo says to the other doctor, "Don't touch that, you don't know what it's connected to." This is the hallmark of working in legacy code, and what it's speaking to is a tremendous absence of locality.
In fact, when I do legacy rescue, which btw is one of my favorite things to do, my first focus is usually on how to isolate the chunks of code I want to change. I am asking myself, how can I create (or confirm) locality where there is none (or it isn't clear)?
Why is locality such a big factor in the success or failure of making changes? First -- as foreshadowed in the stuff about "human" -- it works with human strengths. Second -- it takes seriously the fact that the targets for our change are elements in complex adaptive systems.
Aside: Software is *not* complex adaptive. Seeing it as such is mistaking one's perspective for the reality of code in a Von Neumann architecture. No matter: a) your perspective is definitely complex adaptive, and b) *making* software is definitely complex adaptive.
Locality is important at the human level because of the severe constraints of our bodies. The relationship between the conceptual neighborhood-size of a task and the human performance of that task is quite strict, with a severe knee.
Locality is important when the target is complex adaptive because the causal loops are, in Hofstadter's terms, "strange", multi-layered, bi-directional, and reactive. That makes "globality", in practice but also in current theory, virtually impossible to achieve.
Our extraordinary success at building large machines out of smaller ones connected in simple uni-directional non-reactive ways often masks just how genuinely difficult complex adaptive systems are to understand. But they're not machines, not uni-directional, and not passive.
Locality, then, is about the size of neighborhood. It implies nearness, between changer and changed, between before and after. A change-harvester asks the same question over and over again: what is the nearest easiest change I can make that will have a detectable outcome?
If you think about this, you'll realize there are *lots* of possible changes that might fit that "easiest nearest detectable" criterion. Choosing between them is the topic of another adjective, "oriented", and we'll be taking that angle up soon.
In the meantime, tomorrow, at work, ask yourself "what's the easiest nearest change with a detectable output that I can apply?" Try applying it. Get a feel for what things you're already doing that satisfy locality, and what things you're not. You might find some surprises.
My team at geepawhill.org wants you to know these long twitter threads become both blogs and podcasts, and that you can subscribe for free, to get them via email, rss, or your favorite podcast system. It's spam-free, and we never pass your info on.
Subscribe today!
Subscribe today!
