Read on Twitter
Rework Avoidance Theory, or RAT, is likely slowing your team down more than rework ever would. Let's talk a little about that today.
I am writing these geekery muses in a time of great turmoil, but for the most part they're not addressing that crisis. They are momentary respite, for me, and hopefully for you. They're not the main story.
Stay safe.
Stay strong.
Stay angry.
Stay kind.
Black lives matter.
Stay safe.
Stay strong.
Stay angry.
Stay kind.
Black lives matter.
Rework Avoidance Theory is a cluster of related ideas seeing a change as having a clear start-point & end-point and a straight & stable path between them. It draws its inspiration largely from logic based in relatively straightforward metaphors to the physical world.
One metaphor is that of a footrace. The change is a well-marked track with one runner. It assumes 1) linear cost of step regardless of size, 2) stability and perfect knowledge of path and endpoints, and 3) indifference to post-footrace consequences.
A second metaphor is that of seeing the change as a finished product, built in standard parts by isolated individuals, assembled at the end. It makes similar assumptions to the footrace idea, but also assumes free cost of parallelism and high bonuses from specialization.
Metaphors are just tools for reasoning, and these two have broad application to a number of different kinds of enterprise. They're not insane or stupid or malevolent. In fact, when their assumptions are met, they can produce excellent methods for change.
The problem we encounter when we apply them to software development is that those basic premises, the assumptions, are not reliably valid. Necessarily, then the conclusions we draw from using them are also not reliably valid.
One conclusion that occurs constantly is that our chosen method will be inefficient if it ever does the "same thing" twice. That phrase, "same thing", can have several different (and sometimes conflicting) senses, but RAT tends to take any notion of same thing and forbid it.
