Microtest TDD: The Big Picture

I think of my style of coding as "microtest TDD". That can be misleading for folks, so let’s take a walk over a few of the ideas, implicit and explicit, that make up the approach.

First things first, bear the money premise in mind in all that follows, to wit:

"I’m in this for the money."

In the software trade, we make money by shipping more value faster. This is why I adopt these practices, because when I do them, I go faster.

In particular, I don’t do them out of a fondness for artistry, intellectual purity, common decency, perfectionism, or theory. I do them because they are the best way I’ve discovered, so far, to ship more value faster.

Next, though I call what I do "microtest TDD", that’s really a shorthand for a whole bundle of practices. A more accurate name would be something that captures, in the big picture, working in the smallest ready-to-ready steps I can formulate. That’s a lot of words, tho. 🙂

The practices include things that are "coding", and they also include things that are "collaborating". Professional software developers have to do both, all the time, freely intermixed. Strong pro’s do both of those well.

Some coding-centric practices I do: microtesting, refactoring, frequent commits, trunk-based development, spike-pathing, evolutionary development.

Some collaboration-centric practices I do: pairing, mobbing, haykumeer protocol, direct customer involvement, continuous integration, standups, retrospectives, pull and swarm.

I don’t pay much attention to the distinction: they’re all practices, and I employ all of them, and occasionally some outliers, too, in my efforts to find and implement ready-to-ready steps.

Next, I can divide my work into roughly two modes. Sometimes I am "path-finding", which means looking for sequences of smallest-ready-to-ready that get me what I want. Sometimes I am "path-following", which means actually implementing those sequences.

An easy way to distinguish: when I’m path-finding, I throw away way more typing than I commit. When I’m path-following, I commit way more typing than I throw away. There are borders between these, gray transition-y areas, but mostly I’m well inside one mode or the other.

I spend significantly more time path-finding than path-following. It is the hardest work I do, far harder than path-following. But it’s also, for me, the heart of the job.

Occasionally, with very small problems, the finding and the following are happening at the same time: I roll little tests I don’t know how to pass but I’m sure I can get to pass, and then I pass them. That’s hardly rare, but it’s not my most common case, either.

Next, I believe that my productivity is generally dominated by two terms of the production equation. 1) The internal quality of the code I start with. 2) The size of the steps. Correspondingly, I obsess with both of those concerns. 🙂

The two biggest terms in the production equation are "how skilled am I" and "how hard is the domain". But the thing is, both of those are out of my ready and direct control. Not that I can’t change them, but I can’t usually change them at a time-scale that matters.

But the next two biggest terms are internal quality and step-size. And those are far more directly controllable by me, so that’s where I give my attention.

The practices I use to keep internal quality high are primarily TDD in the narrow sense and refactoring in the narrow sense. My experience has been that my style of TDD almost forces a certain level of internal quality, and the refactoring either enables that or refines it.

And the step-size? Well, for that my main practice is what I call spike-pathing. It means that I use path-finding code-I-don’t-commit to discover the path-following code-I-commit.

So that odd rambling muse is it for now, but I see it as setting a context in which I can discuss in much greater detail, each of the practices, how I use them, and how they relate.

I have written or spoken at one time or another about nearly all of these practices. I intend to do so again, and to do so in greater depth, practice by practice.

In the meantime, though, since you so graciously read all the way to the end of this:

AMA.

I love talking and thinking about this stuff, and if anything I’ve said here triggers your curiosity, well, ask me about it.

The GeePaw Podcast

If you love the GeePaw Podcast, show your support with a monthly donation to help keep the content flowing. Support GeePaw Here. You can also show your support by sending in voice messages to be included in the podcasts. These can be questions, comments, etc. Submit Voice Message Here.