Change Harvesting

The Cost of Rework Avoidance Theory

To make the case for Change Harvesting as an approach, it’s important to understand that the cost of Rework Avoidance Theory isn’t imaginary or subtle, but both concrete & quite high. Geekery’s not the most important story for me right now, it’s really just comfort food. Rest, but don’t get distracted. Black lives matter. Stay safe, stay strong, stay angry, stay kind. We can change this. We’re the only thing that can. The most essential aspect of the RAT (Rework […]

The Cost of Rework Avoidance Theory See Full Post

CHT Means Different Design Imperatives

Change-harvesting software design centers "online" brownfield development: change-centric thinking. Most older sets of design imperatives are based in "offline" greenfield development: build-centric thinking. The differences can — and should — lead to design disagreements. This week, regular like clockwork, we shoot yet another unarmed Black man in the back, and we quietly arrest a white man carrying a long gun he has just used to kill people. Stay safe. Stay strong. Stay kind. Stay angry. Help us change this. Black

CHT Means Different Design Imperatives See Full Post

Human-less Change Fails

  A lot of the reasons that change fails, inside & outside technical organizations, come down to one broad statement: the people who have to make the changes are humans, and the people who want them to make the changes have not successfully taken this into account. Before we proceed: Changing a software development process is kind of a sideshow to me right now. Changing the world out on the streets is the real story. Black lives matter. Please go

Human-less Change Fails See Full Post

CHT-Style Implementation

When we did our compare & contrast of the working models underpinned by Change-Harvesting theory (CHT) vs Rework Avoidance Theory (RAT), we temporarily sidestepped the specific differences of the implementation part. Let’s drill in on that today. Read the first post here: Change Harvesting vs Rework Avoidance It was quite a sidestep: other than the implementation part of the two models, they have much in common, with the key difference being the highly iterative nature of CHT’s approach. If we

CHT-Style Implementation See Full Post

Change Harvesting vs Rework Avoidance

Let’s compare and contrast the RAT (Rework Avoidance Theory) model of software development with the CHT (Change Harvester Theory) model. The differences are multiple and pronounced, so this may take us a while. It is not rote for me: there are many more important things to be doing right now than geekery. I’m actively supporting my friends & family out there seeking equity in the streets. Stay safe, stay strong, stay angry, stay kind. Black lives matter. I want to

Change Harvesting vs Rework Avoidance See Full Post

Iterative User Value in Flows

A flow app, one that steps the user through an acyclic graph, typically gathering info at each stage, can be built to provide iterative user value by gradual refinement. Let’s look at how that’s done. Before we get into it, for me, and maybe for you, too, geekery right now is not the most important story. It’s just comfort food. If you’re out there working for change today, I support you wholeheartedly. Black lives matter. Stay safe, stay strong, stay

Iterative User Value in Flows See Full Post

The Correlation Principle

The correlation principle says that our productivity is tightly correlated with the internal quality of software. The two go up together, and they go down together, and you can’t trade away the one to get more of the other. Let’s talk it over. I remind us that geekery isn’t the main story right now, though you and I can use it as comfort food. Keep working on changing the world. We can do this. In fact, we’re the only thing

The Correlation Principle See Full Post

Iterative User Value

How do we iterate user value? How can we follow the "more smaller steps" approach and still deliver a positive experience for the user? Today let’s look at some ways to approach this problem. It’s important for me to remind you that, for me and many others, working for equity in the world is far more important than geekery. I regard this as a side-story. Stay safe, stay strong, stay kind, stay angry, please, because black lives matter, and we

Iterative User Value See Full Post

Pathing: A Style of Laying Out Work

I do "pathing" when I project my work into the future: laying out a sequence of work steps, where each step ends with the code in a shippable state. More than design, and more than planning, pathing is a kind of work-style, and it brings me several benefits. Here in the US, citizens are out in the streets on a quest for equity, and the truth is that geekery just isn’t the main story. If you’re out there working for

Pathing: A Style of Laying Out Work See Full Post

Retrospectives: Variety is Key

I strongly recommend high variation in both format and facilitator of retrospectives. I don’t hear this take often, and I certainly don’t see it at a lot of shops, but I think it has tremendous merit. Let’s talk it over. I don’t wanna be pro forma, & I know I’ve mentioned this a lot, but I gotta say it again: for me, and for some of you, geekery is a side story right now, when people are out in the

Retrospectives: Variety is Key See Full Post

Scroll to Top