2020

Second-Order Refactoring: Swap Supplier and Supply

Programming, Refactoring, Change Harvesting, Kontentment / / 5 minutes of reading

As a hardcore user of TDD and refactoring, there are a number of what I think of as “second tier” refactorings that I use quite frequently. In one’s first intro to refactoring, one sees a lot of "rename", "re-order", "inline", and "extract". These are pretty potent tools, don’t get me wrong, but I think of them as, idunno, atoms. I think of these "second order" refactorings as small inorganic molecules. An example of this would be one I call "swap […]

Second-Order Refactoring: Swap Supplier and Supply See Full Post

Working By Stories – A Change Harvester’s Take

Coaching, Change Harvesting / / 8 minutes of reading

Now we’ve seen these basic ideas, human, local, oriented, taken, and iterative. I want to use them in a particular way for a bit. Let’s take some practices we know we like, and work backwards, seeing if/how these "known-goods" relate to those ideas. Let’s talk about "Working By Stories" for this first one. I’ll describe what I/we mean by that, and then we’ll try to look at it through our change-harvesting lens. I had thought to do TDD & Refactoring

Working By Stories – A Change Harvester’s Take See Full Post

Iterative Change – What and Why

Coaching, Change Harvesting / / 3 minutes of reading

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.

Iterative Change – What and Why See Full Post

Taken Change – What and Why

Coaching, Change Harvesting / / 5 minutes of reading

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? Previous articles in the series here: Human Change Local Change Oriented Change 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

Taken Change – What and Why See Full Post

Oriented Change – What and Why

Change Harvesting, Coaching / / 4 minutes of reading

The change-harvesting approach has these elements at its base: human, local, oriented, taken, and iterative. Today, I want to talk about what that adjective “oriented” means. Prior muses on human and local are here: Human Change: What and Why Local Change: What and Why We’ve said that leaning in to the humans in our systems leads us to locality pretty directly. We say “find the smallest easiest nearest change with detectable outcome and make it”. But this gives us a

Oriented Change – What and Why See Full Post

Local Change – What and Why

Coaching, Change Harvesting / / 4 minutes of reading

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

Coaching, Change Harvesting / / 6 minutes of reading

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

Change Harvesting / / 5 minutes of reading

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)

Change Harvesting / / 3 minutes of reading

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

TDD on the Front End

TDD, Programming / / 9 minutes of reading

A recurring respondents’ theme is “TDD is irrelevant in front-end code”. It’s easy to offer/receive this comment combatively, but I think a little more rich discussion of the factors involved might bring us to new and different positions about UI and TDD. Most folks who offer that are living in some sort of JS world: their code is client-side scripts attached to html pages to render various contents received from another application. Their browsers are in effect frameworks, inside of

TDD on the Front End See Full Post

Scroll to Top