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 »
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
Iterative User Value Read More »
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
Pathing: A Style of Laying Out Work Read More »
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
Retrospectives: Variety is Key Read More »
