We change-harvesters say human, local, oriented, taken, and iterative. We talked about human a couple of day ago, let's take on local. A quick sketch of the idea, and a couple of cases will do, yeah?

threadreaderapp.com/thread/1304017…
I write about geekery as a kind of comforting respite from other concerns. But those other concerns are far more important.

Black lives matter. Please help me support and empower this movement for equity and peace.

Stay safe, stay strong, stay kind, stay angry.
When we say that we want our changes to be "local", what do we mean? I think in terms of two nearby metaphors, "neighborhood" and "reach". We want our changes to be in the neighborhood, and we want them to be in easy reach.
Of course, "small" comes to mind right away, but it has its problems, most notably that it almost immediately prompts one to think of numbers, which tends to fire us off into a numbers game that distracts from the fluidity and flex of the idea.
The contrasting approach to local is global. Remember the early eco slogan, "think globally, act locally"? That notion of locality is what we're aiming at. (When we get to oriented change, we'll see the other half in action, too.)
A locality-in-action idea is "ENOF", which means "Easiest Nearest Owwie First". It says, look right around you in the nearby environment, find something you want to change, make it something you can easily change, then change it. Rinse, lather, repeat.
This is in stark contrast to the default idea of how/what/when to change things. Our normal take is to say "what's the *biggest* problem?" Of course, big problems aren't easy to fix, and often tho not always, they aren't remotely nearby.
ENOF -- locality -- says we'll get better and faster results in our changes if we make them in a small neighborhood around us, and we choose the easy ones, and we just keep doing this, over and over again.
(A curiosity to me: old-school geekery is obsessed with over-simple addition of things that aren't actually addable in any straightforward way, but the one place where they add pretty well is in making small changes, and that's the thing old-school geekery routinely ignores. :) )
A negative case: the overwhelming majority of so-called agile transformations are planned & executed as vast global changes, and have led to the widespread use of the phrases like 'Big Agile', 'Dark Scrum', and even just '"Agile"'.
Agile transformation as commonly practiced is a system-installation thing, like getting a new fiber installation in your building. It's all or nothing, it's all at once, it's all now. And it does tremendous damage.
Many of those who founded the movement, or those like me, who were in that first ring of adoptees, are horrified by this. Our vision was one of community and collaboration, in fact we somewhat naively took it as a given. The global agile transformation is anything but.
What is it about these global approaches to change that make them fail so frequently? The shorthand for it is complexity, in the complex systems theory sense, but let's expand that a little, not just taking for granted we know what that means.
1) Multi-agency is spread throughout a software development system. There isn't one guiding mind and motivation, there are as many (or more?) minds in the game as there are players in it. This single factor alone guarantees that global change will run up against local agency.
2) Multi-layered multi-directional causality is present, too: detail A affects higher-level B, which affects sibling higher-level C, which turns right around and affects detail A. Unlike machines, human organizations have bewildering causal connections arranged in strange loops.
3) Global change has to go everywhere at once, which means its pre-conditions have to be everywhere at once. The greatest of these is understanding the change, which is almost impossible to obtain by words or rules alone. Global change runs smack into local interpretation.
4) Efforts to abstract away and simplify all that complication, to render the human enterprise as capable of single-agent single-causality single-interpretation -- "all models are wrong but blah-blah-blah" -- don't stand a chance, no matter how brilliantly powerpointed.
Because of the global approach to change -- and other factors, too, some other time we'll tackle that -- the business of "agile transformation" sits somewhere in reputation between "used car dealer" and "gold dripping ambulance chaser".
Positive case: large-scale transformation of a TDD'd codebase by alternating steps of refactoring and extension, each step a modest local change, each step a confirmed same-or-better from its starting point.
The modern synthesis combines three activities to change code successfully 1) we test the code in tiny chunks, 2) we refactor the code, preserving its behavior via our tests, 3) we extend the code, extending those tiny tests. All three activities are highly local in scope.
What are the factors that make this emphasis on locality so successful? In the same way that global change founders on several fronts at once, local change succeeds on several fronts at once.
1) Agency is restricted in one way and completely free in the rest: if you don't make the existing tests red, you can do anything you want. I have seen teams tell someone in their first week: go add this one test, make it pass, and don't break any of the others.
2) Multi-directional causality is still there, but it's much more managed. The system stabilizes after each local change before we go on to the next one. This gives us a chance to *observe* causality instead of just theorizing about it.
3) Local interpretation is backed by the tests themselves. They form a kind of executable documentation, and they don't let us overlook details or smudge the meaning of words.
4) The elapsed time of a change roughly approximates its locality. Local changes are of small period, typically under an hour. The benefit we gain from this returns to human-ness in several ways. See previous articles on "Many More Much Smaller Steps". o

geepawhill.org/2020/05/29/ste…
You start to get a sense of how important locality can be. Absent locality, we get Dark Scrum et al. With locality, we get a kind of dynamic unity, a thing that seems to stay "the same thing", even as it changes in nearly every respect. Another word for dynamic unity: "living".
Now, don't go off half-cocked: nothing in life is free, except, somewhat regrettably, and maybe even temporarily, 99% of my content.

Locality isn't free, either.
It takes technique. It takes practice. But above all else, it takes the recognition that it is such an important factor in most successful change. You have to see this to start acting on it, and my goal in writing about change harvesting is exactly that, to give you tools to see.
One final point: Locality introduces a problem. If I restrict myself to only small changes, I am implicitly or expliciting plotting a path towards a larger change, yes? How do I relate these two scales?

The next topic we'll discuss, oriented change, will tackle that chaallenge.
Change-harvesting: human, local, oriented, taken, and iterative. Today we spent time with locality, a sense of neighborhood, of action "within our reach". If you want successful sticky change, in nearly any domain, focus on getting to locality.
Thanks for reading. If you like my content, put a ri-- uhhh, subscribe. It's free, spam-free, comes twice a week in full text or audio.

Meanwhile, keep working for change, and supporting those at your side, inside the trade and out.

Black lives matter.

geepawhill.org/subscribe

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with GeePaw Hill

GeePaw Hill Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @GeePawHill

20 Sep
We're talking about change-harvesting: human, local, oriented, taken, and iterative change. Let's consider this adjective "taken" today, and see where we go with it.
I keep saying: these muses are respite for me, and maybe for you, from more important stories.

Partisan thugs seek to turn our nation into a freak show of state violence, white supremacy, vast inequality, & the oppression of women.

Stay safe. Stay strong. Stay angry. Stay kind.
In change-harvesting, we use this word "taken" in multiple senses, but to put it in a single sentence: the change-harvester takes both the substance of and the approach to change from what is already there. We *take* our changes from here, we don't *give* our changes to there.
Read 27 tweets
18 Sep
In our change-harvesting take, we have human, local, oriented, taken, and iterative as our attributes of successful change strategy. Let's take up oriented: How do we reconcile our emphasis on locality against the far-away target that is our goal?
Before we begin, I want to reiterate my support for those folks out in the world who are working so hard for peaceful change in the US.

Black lives matter to me, and I greatly appreciate your effort and risk.

Stay safe. Stay strong. Stay angry. Stay kind.
(We've already discussed human and local. Both will be up on the blog any minute, but you can work backwards here:

threadreaderapp.com/thread/1305179… )
Read 35 tweets
12 Sep
New Oxygen Not Included seed for me: SNDST-A-1551103718-0

Still cashing in my day off. As with last time, I won't walk through the first 60-80 days in any detail. Image
Interesting. That's a *huge* starter biome. A lot of water, but spread far and wide. That's okay, I'll tap the one just right of the arch and take my time gathering the rest together. Already leaning towards putting my two-columns as far left as they'll go.
Okay, today's part of a working day, but last night wasn't, so here's c83 of this seed. Image
Read 25 tweets
10 Sep
Human, local, oriented, taken, and iterative: this is how change-harvesting in software development approaches change in most contexts in the trade. Let's take "human" today, and see where it leads us.
Before we begin, I want to express my continued support for the protestors. They're still out there, folks, still peaceably seeking change, and still risking life & limb in the face of armed violence every day.

Stay safe, stay strong, stay angry, stay kind.

Black Lives Matter.
When we use that word "human", change-harvesters are getting at the fact that, in systems involving humans, machines, and procedures, the humans are the most powerful force. When we seek change while ignoring human factors, we go awry quite rapidly.
Read 27 tweets
6 Sep
To make the case for Change Harvesting as an approach, it's important to understand that the cost of Rework Avoidance Theory isn't imaginary or subtle, but both concrete & quite high.
Geekery's not the most important story for me right now, it's really just comfort food. Rest, but don't get distracted.

Black lives matter.

Stay safe, stay strong, stay angry, stay kind.

We can change this. We're the *only* thing that can.
The most essential aspect of the RAT (Rework Avoidance Theory) is its emphasis on the endpoint: the City On The Hill we call it.

The central concept: define the City rigorously, optimize building it off-line, move in to it only when it's done, and never change it again.
Read 33 tweets
30 Aug
Change-harvesting software design centers "online" brownfield development: change-centric thinking. Most older sets of design imperatives are based in "offline" greenfield development: build-centric thinking. The differences can -- and should -- lead to design disagreements.
This week, regular like clockwork, we shoot yet another unarmed Black man in the back, and we quietly arrest a white man carrying a long gun he has just used to kill people.

Stay safe. Stay strong. Stay kind. Stay angry.

Help us change this.

Black lives matter.
The significance of "online brownfield" vs "offline greenfield" is hard to overstate, in all areas of software development, but especially so when we talk about what makes a design "good" or "bad".
Read 35 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!