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 Avoidance Theory) is its emphasis on the endpoint: the City On The Hill we call it.
The central concept: define the City rigorously, optimize building it off-line, move in to it only when it’s done, and never change it again.
In the RAT’s idea of efficiency, changing a thing is waste. After all, why did we build it all if we’re just going to turn around and change it to get to the City on the Hill? Why not just build it that way to begin with?
This idea, that change is bad, that we should avoid having to change our systems, absolutely permeates the culture of software development, to the point where it is less an intellectual construct and more of a gut-level instinct.
The RAT seems to actually fear change.
The cost of RAT’s sense of finality and its corresponding loathing of change, is concrete and quite high. I won’t even try to list every aspect of it, but let me lay out a few of them.
1) When business considers a new project, they "kitchen-sink" it: feature after feature after feature.
This is perfectly rational, as years & years of working with RAT projects have taught them well: You only get one shot, so make sure you get everything you’re ever gonna want.
Of course, this makes time-to-market, both estimated and actual, far larger. The trade routinely plans (and hardly ever successfully executes) projects on the scale of quarters and even years. Further, it places all the complexity at the beginning and all the reward at the end.
Software development death marches are commonplace, and they start right there, with projects that include everything but the kitchen sink. You can see this kind of thing coming from a mile off.
2) Teams working in RAT mode also "gold-plate" everything they try to do.
This is not business-only or geek-only or UX-only or any of that: at nearly every level and nearly every step, we buy the idea that we must build all and only the parts of The City On The Hill.
This isn’t feature-loading, like the kitchen-sink thing. Rather, it’s making things better than they have to be to do their job. In code, it’s often unneeded generality and predicted later need. In UX, it’s bells & whistles one user in a thousand ever even notices.
In our XP days, we used the term "YAGNI": You Ain’t Gonna Need It. It was our way to remind ourselves as often as possible: solve today’s problem, not tomorrow’s.
The cost of gold-plating, just like kitchen-sinking, is greatly expanded time-to-market. Code is made far more complex than it needs to be, leading to a lack of understanding and confidence, leading to both slower development and defect-laden releases.
3) Finality means perfection, which seems admirable, but it leads inevitably to a fear, rational or otherwise, of imperfection.
This isn’t one cost, it’s several, and it happens at several different levels in RAT-based organizations.
My mom used to say "Lord, honey, do something, even if it’s wrong." What she was getting at was the paralysis that comes from the fear of being wrong, of imperfection.
In software development under the RAT, the stakes of any given decision seem incredibly high. It leads us to freeze in place, and it leads us to fight viciously.
You see, the RAT decision will be binding on us forever, it’s a decision about the City On The Hill. We can’t try an experiment. We can’t field part of our City and see what happens. And of course, the fighting highlights ego, too. I become my decision.
4) We divide the work by "pieces of the City", which we draw strict interface walls between, then hand out to parallel teams for implementation.
Seems like it makes sense, except in so much as it costs a fortune to work that way and it hardly ever succeeds.
The costs here are also multiple: 1) expensive control effort, 2) long-pole politics, and 3) very late validation.
Control: organizations struggle desperately to manage this kind of parallelism. They introduce wait states and sync points, developing lockstep. They add documents and email and handoffs.
Long-pole politics: because such projects inevitably run over budget & schedule, it becomes important to not be "the long pole in the tent": the team or individual whose City-piece isn’t going to be ready. I’ve seen managers purposefully handicap other teams for this purpose.
Late validation: We can’t find out if the code actually implements the City until all the pieces are there. This is a very late time to be discovering a problem. For added piquancy, notice that it’s also at the point of maximum stress, shortly before the deadline.
5) Since the RAT factors above lead to late, expensive projects, it drives business to become perfect suckers for the variety of gimmicks that lean toward "write less code".
Codeless, buy-don’t-build, ML, anything that lets us dispense with programming.
You know they see you coming, right?
Some of these scams make Barnum look like a man of integrity and compassion, a veritable saint of plain dealing.
Codeless, whether it’s in-house or bought, is a joke, this time around and the twenty prior times it’s been "the next big thing" in my four decades in the trade.
I’m especially fond of the natural-language processing variety that’s so hot right now. If you could use sufficiently rigorous spoken language to describe the solution you want, you’d already be a programmer.
And buy don’t build? We’ll just buy the pieces, and there won’t be any programming, they’ll fit together, and they’ll do what we want. My mom will help us make the costumes!
I’ve worked in health-care a lot, where that kind of thing is the rule. It suffers from every problem having a stable of programmers does. The difference? That stable works for you, so you can tell it what to do and when. The people you bought your pieces from: it is to laugh.
So. Let’s wrap this up.
That list isn’t even complete. But at this point, you should be getting pretty suspicious of the sheer cost of Rework Avoidance Theory, an idea that was meant to be about efficiency.
I’ve spent a lot of time over the last year talking about Change Harvesting from a very theoretical level — I’m built that way, what can I say? I know we’ve wandered far and wide, and it seems at times like it’s all just irrelevant philosophical hair-splitting.
But it’s not.
The choice between embracing change and fearing it is a real choice, with real consequences. The cost of fearing it isn’t just based in the simple truth that change comes whether we like it or not. It brings that cost with it everywhere, whether change happens or it doesn’t.
Rework Avoidance Theory (RAT) drives our trade down incredibly expensive roads, providing little benefit, and high risk: it is a perfect formula for unprofitable software development. Understanding the concrete and very high cost of RAT is essential to considering an alternative.
Supporting The PawCast
If you love the GeePaw Podcast, consider a monthly donation to help keep the content flowing. Support GeePaw Here.