Thread by @GeePawHill

Time to take up "iterative", the last, but by no means least, of the bywords of the change-harvesting worldview: human, local, oriented, taken, and iterative.

(The previous thread, "taken", has its own links back to the beginning at "human". It is here:

threadreaderapp.com/thread/1233420…

Most of my muses become blogs & podcasts, go to geepawhill.org to subscribe. It's free and spam-free!)

The heart of the iterative approach is *assuming* change. We embrace it, we plan for it, we expect it, we encourage it, we enjoy it, we see it as the central act that defines what we are and what we do.

A dynamic unity is a unity because it stays "the same", it persists across time. But it's also wildly dynamic: it is undergoing constant change, in its parts, their arrangement, the flows, even its boundary. The single unchanging aspect of a dynamic unity? The changing itself.

*You* are a dynamic unity. Notice two things: 1) Many of your parts are also dynamic unities. 2) The day you stop changing is the day you stop altogether.

So, too, with your organization. It's a DU made partly of other DU's, and it only stops changing when it dies.

In fact, the change-harvester sees the codebase, the individuals, the team, the project, the product, the process, the department and the enterprise *all* as dynamic unities. And seeing them this way has potent consequences.

The most direct and obvious consequence of this stance: if everything is subject to change, we want everything to be as *easy* to change as we can make it, and we want to develop the various behaviors & habits that make change easy.

This is in stark contrast with the standard practice in the trade, which emphasizes above all other value the perfection of a change's final outcome. The change-harvester certainly cares about outcome, but, denying that word "final", she cares a even more about changeability.

Many of the "optimizations for efficiency" the trade adopts only make sense if, somewhere in the distance, there is a finish line, a city on the hill, an endpoint, beyond which we will no longer be making changes. The change-harvester isn't buying: there is no city on the hill.

The premise of these faux-optimizations is that the outcome of perturbing the system is predictable with a linear error epsilon. The better your input accuracy, the better your prediction accuracy. The falseness of this premise is *definitional* of complex adaptive systems.

And that is why we iterate. We make a change, we wait for the system to react, and we make another change, very possibly in exactly the same area we just changed.

Iteration like this works very well with the other adjectives, human, local, oriented, and taken. It supports and reinforces each of them.

When we iterate, we get to work at human scale on local changes, oriented towards a horizon of better, and operating on and with what is already there.

So. Now you've seen the five words. What we need now -- not today, maybe not even this week -- is some examples of how they work together, in real known-sound practice. The natural case, the next one we'll see is the dance we call TDD & Refactoring.

I'm going to do the grown-up responsible thing, and take the rest of the day off. It has been a demanding and exhausting month, and I know for sure that I'm not firing on all cylinders.

I hope *you're* taking care of yourself today, too. We need you, but we need you *strong*.

My team wants you to know we have a private space, the camerata, for people who are pursuing these change-harvesting ideas, separately and together. Come to geepawhill.org/camerata to see what it's all about!