Today’s muse, another damned geepawism: RORA technique. RORA means "Runs Once, Run Away". It is the standard technique in a great many software dev environments.
A developer is tasked with some story. She codes it using a variety of half-assed techniques, including mostly GAK testing. More geepawism: GAK means "geek at keyboard" testing. You know the GAK drill: run the code. Look at the output. Fire up the debugger. Look at the output. Bless it. Ship it.
RORA includes not just GAK-centric testing, but all the things we do whose essential focus is "it ran and it worked, so it must be done." where does RORA come from? One must be sure to understand, i’m not ranting here about developer responsibility or oaths or such-like. RORA comes from two facts. 1) geeks don’t know how to geek well when they start. 2) managers don’t actually understand what we do.
First, the weak-geek source. See, in this trade, we throw noobs over the wall to fight the boche on their first day. We do it over and over. As noobs, they’re mostly conversant with the basic language syntax and one compiler variant. No slur on them. They’re noobs.
So they race through the mud and the barbed wire and the corpses and they charge that story’s machine gun nest. When the shooting stops, they’re dead or the nest is. And they report to us that they did it, and we move another story in front of them.
On the managerial side. Ahhhh, it’s harder for me here, as I generally loathe that world. But I will try. There seem to be three sub-issues.
- Managers press for feature-movement cuz they’re pressed for it.
- Geeks, eager to please, say they’re done when they’re not.
- Managers don’t have the skillset to actually assess done-ness or stability outside of actually trying the product.
All of this adds up to gigantic pressure to go all RORA on things.
Here are some RORA behaviors i’d call out.
Soloing in a normally-paired environment leads to RORA. I can’t overstate the anti-RORA force working with a pair represents.
Not versioning/staging output is classic RORA behavior in a web-service world. When i’m an upstream team, it’s not done cuz it works. It’s done because downstream can use it. And downstream uses it FOR DEVELOPMENT, which means they need it to be stable, version-tagged, or side-by-side with whatever was there before.
Obviously, no automated tests is a very much a RORA-inducer. But i’d go a little further. I need automated tests of a particluar type, which is a muse for another day.
Another RORA thing: does it deploy? If it doesn’t deploy, it ain’t done. If it’s upstream and it can’t be pulled, it ain’t done.
In my current environment, this isn’t true everywhere, the services are all pretty large-scale. This leads to nightmares. If your change is to a large-scale webservice, do you have an in-box version ready for your downstream to pre-develop against? RORA.
Do you have actual pro-active contact with your downstream? Can you auto-announce updates, not a fucking git comment stream, real updates? Do the docs change? Did you change them? If not, RORA.
I offer code-clients the geepaw guarantee. It does what I said it does. It does exactly that. If it doesn’t, call me, 24/7. I’ll fix it. If you’re not able to offer users of your code the geepaw guarantee, you prolly still have RORA aspects to your technique.