Thread by @GeePawHill

Human, local, oriented, taken, and iterative, those are the hallmarks of the change-harvester's approach.

This morning I want to tackle "taken", which is about grounding the substance and approach of our changes to the situation that is already there.

(Want to catch up? Human, local, and oriented are...
threadreaderapp.com/thread/1230701…
threadreaderapp.com/thread/1231623…
threadreaderapp.com/thread/1233068…

My "muses" are available as both blogs and podcasts, go to geepawhill.org and subscribe today!)

Taken has several layers of meaning to the change-harvester, but the simplest way to say it is just this:

To get to there, we want to start from, work with, adjust, and nurture what we have right here.

A couple of examples might tighten this right up for you. We'll take one from changing code and one from changing process.

In the early days of a coding project, everything is new. We're working with a blank page, and our creation-act is almost entirely about adding to that page. One has tremendous range of motion, the freedom to spitball, to write whatever we want however we want it.

In fairly short order, though, our project thickens, with new capabilities, different-but-related tasks, additional datasets, and so on. The page isn't blank anymore, and everything we add to it must still fit with and connect to what we already have.

(The blank-page situation is usually called greenfield, and the full-page is called brownfield. One of the weaknesses of our software pedagogy is how exclusively it focuses on greenfield, given that the overwhelming majority of a project lifecycle is brownfield work.)

As the project transitions from green to brown, our techniques change, and our vision has to change. "What's there now" goes in surprisingly short order from relatively insignificant to tremendously important, one of the dominant terms in our productivity function.

Eventually, we approach legacy, where "what's there now" has so much importance we can barely add function at all. The cross-connections, tacit knowledge, tight coupling, and so on, restrict our range of motion so much we often consider throwing it all away and starting over.

What we do in brownfield work, and of course especially so in legacy rescue, is refactor the code. Refactoring is changing our system's design without changing its function. (Folks out there get confused, but please be certain, that is the literal definition of refactoring.)

And by its very nature, refactoring is "taken": it takes what is already there, and it proceeds in steps to transform it. It does not *erase* what is there, it starts from, works with, adjusts, and nurtures what is there, gradually transforming it to what is desired.

Why work this way? Why don't we just start over with a new blank page? The answer is straightforward: because what we have there now has both vested and ongoing value, and losing either of those would cost us a lot, often significantly more than the new value we hoped to add.

Code we've shipped for a year is already making value. It's already handling exceptional situations. It's already satisfying some of our base. It represents a huge amount of domain knowledge, explicit and tacit. We want *more* value, to be sure, but we don't to lose what we have.

Now map those ideas from changing code to changing process, to altering our complex adaptive value-generating systems. You'll see that the mapping is really quite direct.

Our complex adaptive system -- of people and procedures and machines -- is *already* "shipping". (Unlike our code, our software development team shipped on day 1, and has never stopped doing so.) It already has both vested and ongoing value.

Because of the humans in that system, two aspects from the code world are particularly heightened. 1) The tacit knowledge in that system *dwarfs* the explicit knowledge. 2) The cost of erasing what is already there is so high it's virtually guaranteed to swamp any value we gain.

Remember "human"? We remarked that humans break rules and save systems by doing so all the time. It's because of their tremendous levels of 1) tacit knowledge and 2) situational awareness.

So, at this layer of meaning, "taken" means working closely with what's already there. It's an attitude, an approach. It implies being familiar with what's already there, gradualism, sustainability. And it fits well with the other four terms in the change-harvester's arsenal.

There's one more aspect to this, it will sound a little mystical when we talk about code-changing, but far more pragmatic when we talk about people-changing: ask what is there now what it wants to be.

In the domain of people and process, I hope this is obvious: ask them what's right, what's wrong. Ask them for ideas. *Use* their tacit knowledge and situational awareness. (A side effect of this: people change much more energetically when they're consulted.)

In the domain of code, the more experienced the geek, the more likely she'll say "the code will tell you what it wants to be". Strong geeks really do "listen" to the code. They experience it "wanting" to be arranged a certain way.

My dear friend and fellow leader in this movement of ours, Joe Rainsberger, calls himself a "code whisperer". And he's being clever & charming in using that phrase, but the underlying idea is not an outlier among strong programmers. Hardcore geeks know just what he means.

So you have "taken": The change-harvester starts with, inquires into, works with, adjusts, nurtures, *takes* the changes she makes in a system directly *from* that system. We actively use what is already there.

Time for me to take a break. We have one more adjective to consider, "iterative", and I'll be back today to fire that one up.

Did you know there's a private place for those of us working on these concepts to interact? It's called a camerata, a continuous colloquium of like-minded people working both together and separately on harvesting the value of change.

geepawhill.org/camerata

Join today!