Click the image below to get $75 off Ted Young’s new interactive online class running March 8th-11th 2021. Use special code "GEEPAW" at checkout. Thanks!
Microtest TDD is a "way of coding", not an after-market bolt-on to old-school approaches, and as a result, we have to constantly intertwine our conversation about technique with our conversation about transition.
Geekery’s fun for me, and it’s comforting, but it’s not the most important story going on around us. Enjoy this thread, but please keep working for and supporting change in the world.
Black Lives Matter.
Technique, skills, philosophy, theory, all of these are tremendous delights to me. I love to muse & mull & illustrate & analyze & argue & point, and I greatly enjoy doing it on the topic of the modern synthesis in software development.
But all of this explication & analysis is about a framework of related ideas. And that body of knowledge is a "there", a point on the time horizon we can orient towards.
We, the trade, well, we’re "here".
How do we move from here to there?
Because it doesn’t matter what color the walls are painted in the City on the Hill if we can’t find a path that takes us toward it.
I’ve been a software development coach for 22 years, working with teams in transition towards some flavor of agility, or some technique sheltering under its umbrella. Dozens and dozens of teams, around the world, in every kind of domain & tech stack.
My experience report: I have seen gigantic failures, jumbo failures, extra-large failures, very broad failures, very deep failures, regular failures, small failures, and a handful of successes.
(Seen & sometimes participated in.)
The hallmark of nearly every failure I’ve seen: trying to install something as thick, rich, nuanced, and complicated as TDD in a single instant step.
No. It just doesn’t work. It’d be cool if it did, but it doesn’t, it really doesn’t.
And I have tried harder, and seen many people try harder, and I think it’s time to try different, not harder.
We need an approach to "TDD-izing" an individual, a team, an org, that is a slowly unfolding DAG that we can move ourselves, our code, and our process along, effectively creating a network of paths & trails that will bring us, inch by inch, closer to the City on the Hill.
Today, I want to sketch it broadly, to try and give you a feel for where I’m headed. Here are some of the attributes I want to emphasize.
Most of the failures I’ve mentioned before have had close to their root the cause that the people having to do the work did not think the work was worth doing.
If you accept as I do that TDD is really a worldview change at least as much as a technical one — I think you’d have switched off the GeePaw channel in disgust a long time ago if you didn’t — then it should be obvious: you can’t order people to shift their paradigm.
If you’re a pro, the odds are good that you’re working in a codebase that is far larger than can ever be altered in a "flip a switch" way. It could be 20k lines, or 3m lines. It doesn’t matter, it’s still too many lines of code to change in one pass.
We need to take pieces, small pieces, & move them, one at a time, from "here", to our next staging point. We will have a mixed system, parts of which fit our current definition of righteousness, parts of which don’t, for a long time, & we need to work w/that.
Those staging points, they’re not the City on the Hill. They’re just camps on the path. And we won’t be moving them one time, we’ll be moving them from point to point, several times, over a long period.
An important aspect: this isn’t just about the code, it’s about us, too, as individuals, teams, and our process. What I thought "righteous" was forty years ago, versus 30, 20, even 10, well. It is to laugh. And the code didn’t change, I did. We will, too, over time.
At any given time, elements of our system will be in various states, and those states aren’t a hierarchical partitioning of the space, they’re attributes, tags. We need to know what things have what tags, and to do so relatively quickly & effortlessly.
If I have a piece that is "righeous" — has all the current best tags we have — I never want to make it "unrighteous". I might go sideways, but I don’t want to go backwards. And I also don’t want to re-judge that for every new piece I work with.
Next to ordering people to do things they don’t think are worth doing, the next greatest cause of failure is premature commitment to a tool or a technique. We want our approach to unfold as a conscious series of experiments.
Not only is it easier to sell & explain experiments, it’s far safer. At any given time, some of our pieces will have tags we’re not even sure we like yet. "So far, so good" is cool, but it can be said by a person who jumps off a cliff right up to the moment when it can’t.
One of the challenges every working professional developer has to wrestle with: "when do I deal with this?". We want our approach to emphasize the answer "when you’re ready".
Real programmers work for a living. To do so, they must provide a steady stream of value. They don’t always have time or energy or money to do the things they know would be better. But they sometimes do. And when they do, we want to be there.
7) Patient. Above all, patient.
No elaboration here, except to say:
A pig like that, you don’t eat all at once.
This is where I’m headed. I think the way forward for me is to take these attributes and apply them to formulating the way forward for others.
In coming muses, I’ll be trying to combine technique with transition, elaborating both, intertwingled, because I think it’s the only way forward that might work. Voluntary, Partial, Iterated, Demarcated, Experimental, Opportunistic, and Patient.
I’m daunted, but cheerful. 🙂
If you love the GeePaw Podcast, consider a monthly donation to help keep the content flowing. You can also subscribe to get weekly posts sent straight to your inbox. And to get more involved in the conversation, jump into the Camerata and start talking to other like-minded Change-Harvesters today.