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.
Previous Posts in This Series Here:
Human Change Local Change Oriented Change Taken Change
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 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.
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.
