Thread by @GeePawHill

TDD Pro-Tip: RORA (Runs Once, Run Away) is insidious, and although I am an old-guard agilist, I still have to actively resist its charms every day.

Alright, well, look, I figured out after some helpful application of 2x4's to the head, that I needed to *phrase* these pro-tips as advice to me, even when, as occasionally, in my heart of hearts, I thought of it as advice for you.

This is not one of those cases.

I've been working on a project with another hardcore pro agilist for about a year, more or less every day. One of the terms we set to the client early on established an extraordinary amount of freedom for us. None of that "you'll get in trouble" crap one sees at big companies.

We have been virtually *entirely* free to do this project "our way", the way I advocate here, based on my conception of agility, of TDD, of refactoring, of CI, of the whole thing.

Cut to definition of RORA.

RORA means "Runs Once, Run Away". It's not one behavior, but a whole cluster, and the theme of the cluster is stopping the work in one part of the forest to go to another part, even though all that initial work does is barely pass the "customer saw it run and said okay" test.

Have you ever said to yourself, "Well, the code is shite, but it does work, so I guess I'll move on." To yourself, have you ever said that?

If you *have* said, "It's working, shite, and I'm moving on", you now know what I mean when I say RORA.

(If you've not said that, and you don't think of yourself as "still geek-young", I've no idea what prompted you to follow me. :) )

No one gets good at geekery unless the practice of it pleases them: there are a lot of little hurdles, it takes practice to move past them, and if one finds the experience of that practice a fate worse than death -- don't laugh, many non-geeks do -- it won't happen.

No one gets good at *pro* geekery, which is different from the amateur world, without a taste for satisfying others, and for most of us most of the time, the others we satisfy are not themselves able/willing to do what we do.

No one gets *great* at geekery, pro or amateur, without a deep sense of appreciation for characteristics of it that are not visible to those who aren't able/willing to do what we do.

And now we see the violence inherent in the system. :)

To be a pro geek I have to care about shipping. To be a great geek I have to care about other than shipping.

Where those two forces meet, there is an incredible tension.

Now, it's not all bad news when those forces meet: it turns out, and this is central to my understanding of the modern synthesis, there are a great many times when I don't have to choose which force to honor.

TDD, for instance, is about shipping more value faster *and* about felicitous code. That is, arranging my code's testability, a matter of the internal charms of the codebase, does in fact make me ship more value faster most of the time.

Refactoring works the same way. The biggest teamwide term in today's production function is actually the internal quality of the codebase we start with.

(Oh, FFS, there's a major storm that just scared the shit outta me. I have to take a break. This one isn't done. I'll be back as soon as the lightning gets non-scary. I'm gonna go huddle inside with Molly the dog in her thunder-shirt. To be continued soon... )

(Okay, seems clear for a little bit, where were we?)

So, often enough, the two forces don't actually conflict. One can satisfy "ship it fast!" and "make it excellent!" at one and the same time.

But not always. Or, *maybe* always, idunno, but even as an experienced pro geek, sometimes you just can't see how to make those two forces line up so that they're both telling you the same answer to "what do I do now?" When that happens, you have to choose.

This is my advice to me: choose "make it excellent!" unless you have an overwhelmingly strong case for choosing "ship it fast!".

Some of you will balk. But some of you don't have a successful relationship with the person you're satisfying, based on the many and frequent occasions in which you've shipped in the past.

I do.

And here's the thing, about this year of working however we want to: I have not followed that advice well enough. And not following that advice has had consequences that are really icky to me.

Now, at a time when I'd like to move as quickly as I managed in the past when I *did* follow that advice, I am moving significantly more slowly, though the problems aren't actually any more difficult.

And that's really it. I'm taking time out from backfilling to bring my code up to my own standard to share this thought with you.

I renew my resolve: GeePaw, if you have a track record of shipping, and the code works but is shite, the default go-to answer is un-shite the code before you move on. You can override this default answer, my little rutabaga, but make that a conscious choice, not a reflex.

It's beautiful here, very cool, and storming like hell, and tonight I am off with my family to a brewery we like. I am leaning towards a lovely evening, and I hope you are, too!