Change Harvesting

Refactoring: Keep It Running

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

A key value for those who take up the change-harvesting approach: "keep it running". This is actually a direct result of human, local, oriented, taken, iterative, and argues against many finish-line efficiency approaches. Think of a change as a point A, with an arrow coming out of it and ending at a point B. At the two points, we have a running system, but along the arrow, we don’t: our change is in flight. The change-harvester seeks to keep those […]

Refactoring: Keep It Running See Full Post

Chunking and Naming

Programming, Refactoring, Change Harvesting / / 6 minutes of reading

In our continuing conversation about refactoring, I want to go a little abstract today, and talk about chunking and naming. Naturally, a topic thisi important has already been addressed by a stupid joke in the movie Airplane!, so we’ll start there. A passenger is approached by a steward, asking if he might be able to help with a problem in the cockpit. He says, "The cockpit! What is it?". She says, "It’s the little room at the front of the

Chunking and Naming See Full Post

Large-Scale Transformation and the Bias for Action

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

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,

Large-Scale Transformation and the Bias for Action See Full Post

Large-Scale Refactorings

TDD, Programming, Refactoring, Change Harvesting / / 7 minutes of reading

Large-Scale Refactorings — given the recent refactoring-related muses, a respondent asked me to talk about large or larger scale refactoring work. (I love it when people’s questions trigger my writing. Please do ask these things.) First things first, “large scale refactoring” is really a colloquial expression, a shorthand we sometimes use, but in my experience there is no such thing, for two reasons. The first reason is definitional. Remember, refactoring doesn’t mean “changing my design”, it means “changing my design

Large-Scale Refactorings See Full Post

Second-Order Refactoring: Narrow The Question

Change Harvesting, Refactoring, TDD, Programming / / 4 minutes of reading

Another small second-order refactoring for you today. I call it “narrow the question”. If you’re asking an object for data, ask for exactly what you want to know, instead of what you’d need to compute what you want to know. A very simple example: the PlayerView wants to disable/enable some of its controls when the Player is actively playing. In the "before" code, PlayerView asks the Player for its PlayerState and decides, based on its value, whether that means the

Second-Order Refactoring: Narrow The Question See Full Post

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

Scroll to Top