Microtest TDD is an effective change strategy because it dramatically improves our performance at comprehension, confirmation, and regression detection, all critical factors in handling change quickly & safely.
I know how comparatively little geekery matters right now. Sometimes I need a break, and maybe you do, too, so I share.

Black lives matter.

We can fix this. We're the only thing that can.

Stay safe. Stay strong. Stay angry. Stay kind.
We've covered a lot of ground in considering TDD recently. The five premises, the need for a change strategy, the increasing collaboration, complication, and continuity of modern software, and some high-level less-obvious aspects of the practice itself.
I want to put some of these pieces together, and show you how TDD adds up to an effective change strategy.

It doesn't "boil down" very well: as with most conversations around complex systems, the effect is multi-sourced and multi-layered.

This may take us a little while. :)
When we go to change code -- and remember, adding features is still changing code -- there are 3 limiting factors in our performance: 1) How well do we grasp what's there? 2) How quickly can we confirm our change works? 3) How quickly can we confirm our change doesn't regress?
Every way to write software can be viewed as a mixed package of constraints and freedoms. Microtest TDD's package is different, both from the old-school approach and from test-later approaches. Those different freedoms and constraint are what give TDD its comparative value.
Remember twinning? That's where we build two apps from (approximately) the same codebase, one shipping app and one making app. And it's that making app that is giving us our value, both when we are *using* it and when we are *building* it.
Most of the freedoms come from using the making app. Most of the constraints come from how we build it. (I sometimes call this its artifactual vs operational value).
1) The making app doubles the visibility of developer intention, for every alternating pair of shipping part and making part. These two parts, in effect, say the same thing about the code in two different ways.
You *can* determine intent by looking only at the shipping part, especially in simpler applications. But the testing part adds a layer of intention that is focused less on how the code does its job and more on what that job actually is. What it's for, not how it's done.
This has obvious benefits for comprehension, heightening the speed and useful of our collaboration, not only with others, but with our prior self, as well.
(If you've never said to yourself "what the hell was I thinking?", I want to take a moment to welcome you to your first week in the software trade. It's a wonderful business, full of exciting opportunity! I am sure you'll go far.)
2) The making app gives tremendous reduction in mental scope. Remember, it puts individual shipping parts or small assemblies on separate microscope slides. This relative isolation means that a would-be changer has very much less to think about at any one time.
Microtests are purpose-built to fit within the rigorous and well-documented limits of human mental bandwidth. They keep the number of independent mental entities within those limits, by design.
Each microtest tests one hypothesis. It doesn't take the car out for a spin. It checks the tire pressure. Or it checks the ignition switch. Or it checks the brake. Or or or. This reduction of mental scope is very likey the single biggest impact of successful microtest TDD.
3) That same isolation is what allows the making app to be so much faster than the shipping app. In most environments, all of my microtests together take less time than firing up the shipping app and clicking on the first button.
The confirmations that we get from the microtest, as we've said, don't tell us that the app is the right app or even that it overall works. But they *do* tell us a given shipping part is doing exactly what we wanted it to do, and they do that in milliseconds, not minutes.
4) The making app develops as the shipping app develops, iteratively, incrementally, and evolutionarily. This process leans heavily into two huge values for the humans that are developing: it yields profluence and rhythm.
Profluence -- a sense of flowing forward -- is one of the great motivators of human activity. The rapid cycling between the shipping part and its corresponding making part "adds up", providing, well, simply put, increased satisfaction.
And the rhythm, alternating tension & release, does the same thing. It provides a beat to the work, and every time we release our tension with a green bar, we give ourselves a tiny jolt of dopamine, providing, again, increased satisfaction.
Now, there are certainly people who'll tell you that the satisfaction level of the developer is not an important factor. Those people are mistaken, and we have well over a century of research establishing that beyond any question.
5) The making app leads to tightly directed debugging, which is both easier and faster. Debugging will always be with us, but TDD'ers consistently report both *fewer* and *shorter* debugging sessions when they're using TDD.
It's because of the speed and the isolation provided by the making app. Have a theory about some problem in the shipping app? We add tests -- hypotheses about shipping parts -- in typically a minute or two. And we can fire up the making app in seconds to confirm or reject.
6) The making app forces design constraints in the shipping app, and those design constraints align very nicely with our most current sense of "good design".
We talked about old-school design theory and the relative infrequency of change, but that was only relative: many of those designs had built-in support for *planned* change. They had a great deal of expected cold-swap support, for different hardware, for multiplicity, and so on.
Microtest TDD honors every one of those design principles, but with an assumption of *unplanned* change. And it not only honors them, it actively reinforces and sometimes even requires them.
You *can't* microtest TDD bad designs: large classes, God classes, multiple responsibilities, heavy implementation inheritance, bad names, long complicated functions. Putting it bluntly, TDD'd designs are consistently "better", in those old-school terms.
Standing back now, do you see the connection between each of these factors and a higher performance at comprehension, confirmation, and regression detection?
As I wind down, I want to offer once again an important caveat: TDD is a rich & complex skill, not a simple add-on technique, but a whole different way of seeing the problem of change.

It takes learning, and it takes practice.
Tho I'm actually kind of tired of writing about it, in coming muses I want to talk about some problem-patterns: common situations we encounter as TDD'ers where "naive" TDD will get us into trouble. For those, we need to add answers & alternatives to our technical repertoire.
Learning those isn't free, and especially learning those while we're on the job isn't free. I want to move towards an approach to TDD adoption that gets those into our toolkit in a rapid & smooth way.
Microtest TDD is primarily about effective change. It magnifies our performance by easing comprehension, confirmation, and regression detection. It does this in a variety of ways, with much synergy between them.

It is an effective strategy for change, and we need one.
Thanks for reading. If you like my work, two things:

1) Subscribe. Free, spam-free, full-text/audio, and it helps me. geepawhill.org/subscribe

2) Go make change, in the trade and out.

Stay safe. Stay strong. Stay angry. Stay kind.

Black lives matter.

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with GeePaw Hill

GeePaw Hill Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @GeePawHill

16 Jan
ONI: It's c423. I'm nearly done with this wavy space frame from Tony Advanced. This is a quarter of the sky.
The concept: have a thin layer of petroleum constantly running down that staircase. When the doors open, the regolith drops at 300c, and rapidly dumps its heat into the petroleum and the tempshift plates.
The now very hot petroleum is pumped into a steam turbine chamber, which gives some power, but also deletes the heat. Unusually, this is a pure heat-deletion rig, no active cooling.
Read 11 tweets
11 Jan
I got one of those messages I sometimes get from a reader, telling me that including my politics in my muses/blogs is off-putting.
As a general rule, I don't bother to respond to these. I gain and lose followers all the time, everyoen who makes content does, for all sorts of reasons, and that's just one more.
Today, though, surrounded by <waves hands> all of this, I feel like I want to give a more full statement on the matter.

Read 15 tweets
11 Jan
ONI: Off to bed at 11, so I gotta little bit of time, and doomscrolling is breaking my heart. I accidentally walked away and left things running for five hours, so we're back at c380. <sigh>.
Well, glass half full and all: I wasn't happy with the oil wells anyway. I need a rig that doesn't dump steam. I thought this was a matter of gas pressure, but I misunderstood: It's actual cooling. Since I get a free do-over anyway, I'm going to finally use that cold ph2o cache.
I am going to use a switching loop this time: run a pipe through all three wells with the cold ph2o, but have it on an inline thermo sensor, and let it loop through them until around 80c, then dump it to o2 supply. That oughta do it, but it may take a while.
Read 4 tweets
10 Jan
Before we can make the case that microtest TDD is an effective change strategy, there's a few high-level aspects of it that we need to highlight. We tend to take these for granted in our case, but newcomers won't already know them.
More even than before, geekery seems irrelevant. We're living the natural outcome of a politics of hatred & deceit. This content is one way I find respite, and maybe it will help you a little, but...

Stay safe. Stay strong. Stay anrgy. Stay kind.

Black Lives Matter.
Today, I'm writing for the newcomer. It's going to be a little rambly, because the ideas aren't partitioning a single conceptual level into its component parts. Think of me as going over a text with a yellow highlighter, bringing out some points newcomers might not readily see.
Read 32 tweets
10 Jan
Sippie Wallace, w/Albert Ammons and his Rhythm Kings, "Bedroom Blues".

Wallace was famous at the time, but was made more famous by Bonnie Raitt's covers of her. Ammons was not just a *killer* pianist, he was also an excellent band-leader, who wanted his players to shine.
I sometimes admire a pianist for having a left hand as strong as the right, but with Ammons his gift was that his right hand was as strong as his left. I got takes, kids, serious takes, that make a person gasp.
Read 4 tweets
10 Jan

This is called "Life in a Northern Town". It's by Dream Academy.

I mean, idunno, sometimes ya ring a bell. And if you ring the bell one time in your whole career? Well. You know what, you rang the fucking bell, dint you?
I bought the collected William Carlos Williams, and I put it in the bathroom. And I read it, all of it.

He rang the bell a dozen times.

Can you imagine that? To ring it *twice*, to ring it more, to ring it and ring it?

I can't.
Read 4 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!