In our change-harvesting take, we have human, local, oriented, taken, and iterative as our attributes of successful change strategy. Let’s take up oriented: How do we reconcile our emphasis on locality against the far-away target that is our goal? Before we begin, I want to reiterate my support for those folks out in the world […]
Change Harvesters Orient Their Changes Read More »
We change-harvesters say human, local, oriented, taken, and iterative. We talked about human a couple of day ago, let’s take on local. A quick sketch of the idea, and a couple of cases will do, yeah? Previous Post: Change-Harvesting Emphasizes the Human I write about geekery as a kind of comforting respite from other concerns.
Change Harvesting Makes Local Changes Read More »
Human, local, oriented, taken, and iterative: this is how change-harvesting in software development approaches change in most contexts in the trade. Let’s take "human" today, and see where it leads us. Before we begin, I want to express my continued support for the protestors. They’re still out there, folks, still peaceably seeking change, and still
Change Harvesting Emphasizes The Human Read More »
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
The Cost of Rework Avoidance Theory Read More »
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
CHT Means Different Design Imperatives Read More »
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
Human-less Change Fails Read More »
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
CHT-Style Implementation Read More »
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
Change Harvesting vs Rework Avoidance Read More »
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
Iterative User Value in Flows Read More »
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
The Correlation Principle Read More »
