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 talk not so much about the theories today, as about the working models they underpin and lead to. Those models are a kind of inner core of making software, shaping our activities of course, but also our solutions, and even the problems.
The RAT model sees software development as an off-line program-construction activity composed of these parts: defining, decomposing, estimating, implementing, assembling, and finishing.
We’ll get to the parts in a second, but the CHT model’s lead-in statement is already markedly different. The CHT model sees software development as an interative and on-line program-alteration activity.
"Off-line" vs "On-line". The RAT’s focus is to get to a final state, and then ship it, all at once. During the working process, the thing we’re working on is "off-line". It’s not in the field and no one is using it.
The CHT uses a short initial period to get a crude, even paltry, version of the program shipped. From that point on, the working process is much more "on-line". It is in the field, people are using it, and the focus is on morphing the shipping version to its next iteration.
The RAT builds, the CHT changes. The RAT is indifferent to short-term stepping, but the CHT is obsessed with it. The RAT has no intermediate product, so it doesn’t test until quite late. The CHT ships intermediate product, and tests early & often.
The RAT seeks to get to the final state because it receives no value until it gets there. The CHT seeks to gain partial value almost immediately, and to continue harvesting that value throughout the lifecycle of the program.
Let’s talk about the parts of the two approaches. I’ll use the RAT’s six parts as the structure, but there’s no one-to-one mapping onto CHT. Rather, CHT re-mixes, re-emphasizes, and re-scale’s the RAT parts, so the counterpoint of CHT will come out a little muddy.
Defining: the RAT spends a lot of effort rigorously defining a final and distant endpoint. The distance is important, and so is the finality. The scales we’re operating at are months, quarters, even years, and the focus is on shipping a final product, an end to the process.
What we are building in the RAT is a "City On A Hill", a finished & occupied place, with a rigidly fixed architecture, standardized roads & buildings & paths & uses. This means we spend a great deal of effort defining "right" in advance.
The RAT is based on mercilessly optimizing the path to the endpoint, that’s why we have to be so rigorous about the definition: we can’t optimize a path to somewhere we don’t know.
The CHT, by contrast, spends its defining effort on a much smaller goal: it seeks to define a temporary and nearby nextstep. It doesn’t deny the existence of distant targets, but "orients" towards them as it defines the nextstep.
Decomposing: The RAT decomposes its endpoint into "components", smaller separate final pieces that will ultimately add up to the distant target. Think of individual buildings or roads in the City On The Hill.
The RAT usually requires each component to be as rigorously defined as the City itself: the boundaries between components have to line up perfectly to pull this off. This is especially important in the RAT because it allows the optimization of parallel development.
The CHT decomposes its nextstep rather than an endpoint, into "changes", smaller sub-steps which can be executed and shipped in series, to get us to that nextstep without losing the value we’re receiving from the on-line system we’ve already shipped.
Estimating: The RAT estimates the construction effort of each component, adds them together, distributes them to teams & individuals, and ends the planning stage of its working process.
Shipping dates are very important in the RAT, remember, because we get zero value until we get to the end. It means that we have to gather resources & people, assess costs, and store up a complete budget, in advance, before we start any work.
The CHT also estimates, but at a much smaller scale and with correspondingly less effort and actual greater reliability. It’s because the nextstep is rarely more than a few days out from where we are now.
Because the CHT is on-line — it’s already shipped — it is already harvesting value. This, plus its relative size, make the budgetary requirements much lighter and looser.
So pause for a second here. I’m hoping you’re beginning to see what I mean in saying that the CHT re-mixes, re-emphasizes, and especially re-scales the same parts as the RAT.
In both models, we define, we decompose, and we estimate. But what we’re defining, decomposing, and estimating, is significantly different, and the scale of what we’re defining, decomposing, and estimating is wildly different, by many orders of magnitude.
CHT isn’t a tweak to RAT, or a slightly altered bastard child. It’s a very different beast. It requires technique, and it requires practice, and it requires us to see the work before us and behind us in very different ways.
Implementing: In the RAT, we’re now free to race through constructing the individual components. We optimize this often by building them in parallel.
In the CHT, we’re now free to race through executing its changes. We do this in serial, one change at a time. These changes are very much smaller than RAT’s components, down to the point of an hour or two each.
Actual implementation in RAT and CHT is quite different, but somewhat out of scope today. We’ll just say: one’s technique for working on an engine that is stopped is quite different from the technique for working on it while it’s running.
Assembling: The RAT waits for all of the final components to be completed, and it then assembles, usually tests, and ships them. This is the culmination of that parallel optimization we’ve mentioned. We set out all the pieces on the shipping frame, turn them all on and run them.
The CHT has no real correlative to assembly. The changes are shipped as they’re completed. The style does not permit deferring the testing.
Finishing: The RAT ends the project. It either dissolves or re-targets the individuals & resources used for construction. It’s over. The City On The Hill has shipped, and now it’s just operations: minor manual tasks and running the help desk.
The CHT doesn’t have a clear demarcation for "finishing". Rather, over a period of time, we find fewer and fewer changes we believe we could harvest value from, and eventually a tiny devops coterie keeps the app running & stable until it’s decommissioned.
So there you have it. Before we go, I just want to quick-like-a-bunny revisit the change-harvesting vision. We’ve been busy looking at pieces of it for a while, and explaining RAT theory and how it fails, and we might have lost track to how it’s all connected.
The change-harvesting view regards change in complex systems involving humans as being a self-similar-at-scale identifiable and optimizable activity, regardless of domain. We can use its ideas to enable change in code, processes, individuals, teams, and organizations.
Change-harvesting says that the optimal substance and style of change has five properties. It is human, local, oriented, taken, and iterative. It is the deepest part of my intellectual approach, and its theory underpins most of my work in geekery.
Today, we looked at the differences between the implied working model derived from Change-Harvesting Theory (CHT) and compared them to that of Rework Avoidance Theory (RAT).
I hope it was useful for you to read. It was very useful for me to write.
Supporting The PawCast
If you love the GeePaw Podcast, consider a monthly donation to help keep the content flowing. Support GeePaw Here.
It seems that you are comparing waterfall development with agile practices, but using different nomenclatures. Is that correct?