Thread by @GeePawHill

Continuing on our conversation about large-scale transformations, I want to talk about change-harvesting's "bias for action" and tell you a weird thing I did in kontentment the last couple of days.

Change-harvesting takes the stance that our most reliable strategy for change is a highly iterative process of act-look-think, in roughly equal proportions, repeated in small local cycles. We oppose that approach to look-think-act, emphasis on think, in large global cycles.

This opposition is, of course, not a philosophical light-switch, an all-or-none thing. If you abstract away the locality factor, a series of five a-t-l's looks like an a followed by a series of four t-l-a's, followed by a final t-l. :)

So the difference between these issues has to do with the locality and its implications and the relative proportions of the thinking, looking, and acting. The change-harvester wants maximum locality, and wants equal effort applied to the thinking, the looking, and the acting.

When we contrast the two approaches, the change-harvester and the more standard trade approach, we use one as the base and one as the difference, and this leads us to the language saying "bias for action".

Given a large-scale transformation goal out on the horizon, the change-harvester thinks, "what's the most local action we could take that might bring it closer?" She then takes that action, looks around at her new position, and starts over.

Given that same transformation, a traditionalist is far more likely to start by drawing a reasonably detailed and meticulous line from here to the faraway goal, hesitating to take action until she is quite certain she's got that path right.

So let me tell you about this bizarre thing I did to the kontentment app in the last two days.

kontentment's in kotlin, and it uses the openjdk 13, open javafx, and tornadofx, all open-source -- it's open source, too. And in its editing mode, it plays videos, with graphical overlays that "live draw" over the video.

I have 1 horizon-target for kontentment that is ridiculously far away, and it implies another is pretty damned far away. Ridiculously: I want it to be far more usable by people. Pretty damned: I want the video-playing to be way more like a typical video-editing environment.

The app currently uses javafx's MediaPlayer. It's not very performant, it's not a big priority for the javafx folks, it can't play many legit video formats, it doesn't give fine control, and so on. Without going in to too much detail, it just ain't up to it.

Casting around for alternatives, one finds vlcj, which is a set of java bindings for the vlc rendering engine, the same one inside the vlc player, which I suspect is the most commonly used open-source media player around, and is certainly my favorite media player.

So let's replace JavaFx's mediaplayer with the stuff from vlcj, yeah? That's the first level of me getting quickly to, "seems like it'll get me closer to the horizon". I don't *know* that it will work. And I don't *know* what I will do after that. But I'm going to act-look-think.

So now, I have a target that's, well, not ridiculously far away, and not pretty damned far away, but in fact, it's still nervous-makingly far away.

Why nervous-making? Several reasons, but the one that worried me the most: my build is 1) openjdk and 2) open javafx and 3) kotlin and 4) tornadofx and 5) relatively poorly written. vlcj isn't. Further, making it work will put me in one of my weakest suits: infrastructure.

So I found a reference app showing vlcj using a nanotimer and writing to a javafx buffer, in the form of a complete, somewhat basic and crude mediaplayer.

And now we get to the bizarre. I copied the entire dependency tree into my build, made intellij transliterate it to kotlin, and gave my codebase, effectively, two mains, one that runs kontentment, one that runs the reference app.

We're talking about copy/pasting 15-20 files from some random project off the internet right into my build, with basically zero understanding of what I was copying. This is stack-overlow with a vengeance, with as little deep thinking and reasoning as one could imagine.

Of those 20 classes, I am likely to keep maybe 30 lines or so, possibly not even that much, since really what I'll want is to make that code "my own", which will most likely involve completely re-writing it based on my forthcoming full grasp of the underlying concepts.

This took three tries, by the way, maybe 4-5 hours all told. (The gradle/intellij interface is wobbly, and the java<->kotlin transliteration is only "pretty good", and required human intervention to get to really work.)

The standard think-act-look approach would have looked very different. It would have amounted to all the thinking/studying/reading required to determine, in my head, whether it was possible to get this arrangement to work.

Since kontentment isn't already factored to just absorb the change, I would also have had to refactor it to create the right hole. Thinking through that, remember, entirely in my own head with almost no confidence, would have taken even *more* thinking before action.

Now, notice, this isn't a story of how hero-GeePaw is a giant among geeks, and now I have this totally sexy embedded vlcj thing inside kontentment. I don't have that. What I have is a silly two-headed app with tons of irrelevant code that doesn't add a single feature to my app.

But that's not true. I have a lot more than that. 1) prima facie proof that vlcj will work in my build context. 2) a codebase that contains working vlcj *and* kontentment: all in one experimentation tool. 3) the boost to my juice of having completed an action.

In the think-act-look, disproportionately think, spread over a much longer cycle, I would have none of those three things this quickly.

"Let's think this all the way through" and "let's do something" aren't really light-switch opposites. As geeks, we bounce back and forth between them all the time. But given a choice, the change-harvester prefers "let's do something".

In fact, the change-harvester spends most of her thinking time on a particular question: "what's the easiest do-something we can take to prove our idea won't work?"

Bizarrely bolting an internet-copied reference app into my kontentment build was the easiest do-something I could think of to prove that my vlcj idea wouldn't work.

It succeeded by *failing* to prove that. :)

Now I have days and days ahead of me, a lot more do-somethings. But I also have fresh energy, greater confidence that I'm not on a dead end, and everything I need *inside* my do-something-tool, the build.

The change-harvester acts then looks then thinks, in equal proportion, in tight local cycles. Compared to traditionalist approaches, this one has a "bias for action". The concept is important in all large-scale transformations, be they of code or individuals or teams.

Want more? I have a remote town-hall session this Friday. A short talk followed by an active discussion. Our topic:

"Human Change -- Focusing Our Changes Around People"

Seats are limited, to allow lively interaction, so reserve your slot today.

geepawhill.org/town-halls/