Change Harvesting

Local Change – What and Why

The change-harvester uses these five words to describe the properties of successful change: human, local, oriented, taken, and iterative. Let’s talk about “local”. See the previous post “Human Change” here These muses turn in to blogs + podcasts, and you can subscribe to them at geepawhill.org .) When we say we want our changes to be local, we’re talking about neighborhood, some rough concept of nearness, in multiple dimensions. We want a proposed change to be “within reach”. Remembering humanness, […]

Local Change – What and Why See Full Post

Human Change – What and Why

Today, let’s talk about the change-harvesters use of the concept-cluster we describe with the adjective "human". We advocate that both the what and the how are best centered around the humans in our systems. The change-harvester looks at changes — in code, in individuals, in teams, in process & flows, in organizations — and sees that ,successfully applied change is human, local, oriented, taken, and iterative, often enough to adopt it as a general approach. So let’s do “human”. The

Human Change – What and Why See Full Post

Multivalence for Change Harvesters

I want to talk about value today, and especially want to consider an idea I call multivalence, which seems quite central to putting the change-harvesting ideas to work. I recently chanced across a timeline convo that by asked what we should call things it would be good to achieve that weren’t things that were directly visible to the customer. “What do we call valuable things that aren’t ‘value’?’ The answer I gave: “value”. Meanwhile, in another part of the forest,

Multivalence for Change Harvesters See Full Post

Lining It Up That Way (Rant)

The reason it’s so important for you to see 100 lines of code on your screen is that you have arranged the code so that 100 lines seems like a sane quantity. What you’re doing is working against your own capability. The reason it’s so important that no one interrupts you for six-hour blocks is that you have arranged the code so that six-hour blocks seem like a sane amount of concentration. What you’re doing is working against your own

Lining It Up That Way (Rant) See Full Post

The Change-Harvester’s Value

The change-harvester’s take on “value” is quite different from the software trade’s “standard” view. To get at that difference will take us a little time. Three differences stand out for me just now, and they have to do with 1) definition, 2) distribution schedule, and 3) temporal stability. I want to take a look at these in a particular context: "the long story". (Aside: I’m mildly sick today, so it’s gonna spill out a little more slowly. It’s dumb to

The Change-Harvester’s Value See Full Post

Readability And Scannability

I distinguish quite strongly between “readability” and what I call “scannability”. I think that our trade’s pedagogues, even our very good ones, conflate the two, and in so doing inaccurately describe programming and ineffectively prescribe remedies. Maybe the way to approach the idea is through your experience of seeing. Humans — most vertebrates, in fact — rely heavily on "seeing". The fabric of our experience is richly visual. A large portion of our neocortex is given over to it. Its

Readability And Scannability See Full Post

My Direction Forward

Here’s a thing that happens: "We tried your advice by not trying your advice except partly where we did what we want but gave it your labels and it didn’t work and therefore you are wrong." Now, if you’ve given that advice for many years, and followed it in your own endeavors, and you, your teams, and many others have succeeded with it, what are you to make of such a statement? Well. Let’s not hedge, the world has too

My Direction Forward See Full Post

Frames in the Software Trade: An Example

We’ve talked about frames adding up to worldviews adding up to cultures, but it all feels pretty vague in its possible importance. We need some informal sense of how this works in practice. In the immortal words of Brian Marick, "an example would be handy right about now." Continuous Integration (CI) is the practice of frequently cycling code through the source vault. People practicing CI do this several times a day. In "git" terms, they both pull/merge/push, depending on language

Frames in the Software Trade: An Example See Full Post

The Kontentment Project

I am in a mood of 1) wanting to geek out a little, and 2) wanting to concretize some key ideas from change-harvesting for my fellow geeks. To do that, I need to give you a sketch of the kontentment project, a desktop app I wrote and use in making videos. The source for kontentment is here: Kontentment – GeePawHill on GitHub I don’t particularly recommend you download it or try to run it. You won’t need to for these

The Kontentment Project See Full Post

The Cost of Changing Microtests

The “How I Work (Test-Driving Mix)” drew some questions and comment. How I Work (Test-Driving Mix) Here’s one: a respondent says, “If I write a lot of small tests and I change how a feature works, I have to change or throw out all those microtests, which is a lot of work.” (The respondent proposed an answer for this problem, and it’s not a bad one, but raises some other questions we might get to later.) The one-liner response: “For

The Cost of Changing Microtests See Full Post

Scroll to Top