Thread by @GeePawHill

When we talk about transitioning to microtest TDD, we have to figure out how to provide the right experiences in the right order. That's why I propose we start by getting the experience of changing a well-microtested graceful class.

Folks, my ideas about changing code are thoroughly entangled with my ideas about changing the world, a topic of far greater importance. Let's geek out, by all means, but let's also act outside the monitor.

Black Lives Matter.

"Create Experiences, Not Arguments" is one of the core habits of change-harvesters. We want to take that slogan very seriously when we approach any significant change to our practice. And microtest TDD, believe me, is a significant change.

A would-be TDD coach or instructor nearly always carries an implicit belief that her victims do not have, drawn from lived experience that they don't have. It is this:

"What we are doing now is much more unpleasant and unproductive than what we'll be doing when we TDD."

Now, we can *argue* that case, God knows I mis-spent my coaching youth doing just that. And that's a start, it really is. Moving from the implicit to the explicit is generally a useful thing to do. But argument -- reasoning, logic, bullet-points, verbal charm -- has limits.

There's a thing that has many fewer limits than any logic, however passionately, articulately, charmingly, presented: having an experience that ends with you saying one sentence:

"Hey! This feels better!"

I learned to shoot pool seriously back in the middle '80s. And the most useful book about it I ever read, in the intro, said that the most useful book to read about shooting pool seriously was _The Inner Game of Tennis_ by Timothy Galway.

Galway starts noobs like this: After showing them how to hold the racket, he stands 20' away underhand throwing tennis balls to their forehand, one-bouncing them, carefully aiming, and letting them swing.

He's watching them, as he does it, aiming the ball just so, until they hit it three times in a row how he wants. When they finally do:

"That's it! That's what it feels like when it's right."

"This is what it feels like when it's working."

That's the experience I want to create in the early days of transitioning. Here's the thing tho, as soon as I have that thought, I'm hammered by figuring out what the word "it" should be.

Doing TDD well is like competing successfully in the small-town tournament. It's a long way from knowing how a well-stroked forehand feels to being able to play against that skinny mean-spirited 70 year old dude who's been out there every day hitting tennis balls since he was 4.

(That illustration is taken from life. The city tennis courts in Parsons, Kansas are named for that guy. I watched him, growing up, and he was like the ancient master from a thousand classic old kung-fu movies.)

So then, can we give them the feel of TDD done right?

I'll prolly get some grief for this, but hey, live free or die:

The answer is "No."

It's a bridge too far.

Or . . . the answer is "Not yet."

Well, what *can* we give them? What's an early "feels like this when it's right" experience? I have tried a lot of different ones, asked a lot of questions, failed many times at creating viable experiences.

But then I had a brain-fart:

What do programmers *do*, right now, all the time, in their day job? What do they do that is much more unpleasant and unproductive than when TDD is worrking well for them?

Programmers change brownfield code, typically code they didn't write, or maybe wrote a while back, typically code that's okay-but-not-great, typically on relatively modest domain problems, typically under a fair amount of pressure.

That's what programmers do, much or most of the time they're programming.

If TDD was working well for them, would doing that feel better?

Oh. *Hell* yeah it would.

That's the early -- maybe earliest -- experience I want them to have: change modest-problem, okay-but-not-great, brownfield code, when that code has strong microtests around it.

A lot of my threads are implicitly about what you should do. But this one, from here forward, is about what *I* *will* do. I want to make a sample of what it is I'm talking about, a kind of "reference architecture" of it, if you will.

I want something modest but not too tiny, with multiple classes, in a domain I can explain pretty readily. No awkwards in the code that must change. My ideal of coverage. Idiomatic in the chosen language.

I want the change to be bigger than a one-liner but smaller than a breadbasket. I want them to be able to determine whether their change worked or not without testing. In fact, I'm entirely indifferent to the question of whether they TDD their change or even test-after it.

The experience isn't "this is how you TDD" or even "this is how you test-after". The expereince is "this is how it feels to change code that's graceful and has strong microtests around its BEFORE.

I'm wanting this to take between 1 hour and 2. Longer, we lose interest. Shorter, it's too toy-like. The answer should not be too obvious, but also not be rocket-science, or require a clever language-corner.

I have a candidate domain, but not a candidate change yet. I think my next step is just to TDD it up stand-alone, operational to a certain point, then consider the possible interesting change.

Short domain description: you have items. Items have tags -- single words associated with them, many-to-many. Type a query string, ands, ors, nots, and tags, get back the items satisfying it.

(This is from my current night-coding project, called tagster, but as I say, I'll do it standalone for this purpose.)

Concept: Ship a rev of the code without a change, let my friends play with it a little in its working form, and mine *their* ideas for what the good change will be.

Concept: TDD it to the same story-test level *twice*, but using a different implementation each time. Take the tests away from one of them as a NO-TESTS experience to contrast with the TESTS experience.

If we're going to help people unfold TDD, we're going to have to attend to their experiences along a fairly long path. One proposed experience: change modest brownfield code in the presence of excellent microtests and see how it feels.

Thanks for hanging in. I got some code to write. :)

If you like my stuff, subscribe. Free, spam--free, full-text or audio.

geepawhill.org/subscribe

And please, please, embrace change, in the code, yourself, the team, the org, the trade, and the world.

Black Lives Matter.