Here’s a little something I wrote on Hill’s slack group. I’ve edited it lightly.
TDD is hard to do well. It feels slow. When done well (cf. hard), it returns rhythm and confidence. It opens a mind space for exploration. It provides early grasp of the realities of our imagined design, while it is still malleable, able to be changed. Unfortunately, the beginner can’t choose the right steps very well, and has not learned to discern the rhythm, nor to sense, much less adapt, the nascent design. Many do not understand design at all well, and are quite incapable of seeing what’s at hand. Others understand design in the large, as a big thing pre-decided upon, waiting to be built. While the mind is in these “beginner” states, TDD quite literally makes no sense.
Some TDDers can sense in their body when they’re going well, or going poorly. Tension increases as we become less confident in our code. We use the change in feelings to adjust how we work. Unfortunately, many people have long since decided that that sense of impending doom is just part of programming. They cannot use it as a resource.
In this light, in this soil, TDD can probably not take hold.
And TDD doesn’t stick, even after years of doing it. I’ve seen a whole team learn and use TDD for years, due to some combination of desperation, refusal to give up, Beck charisma, and group commitment. When that team broke up, I think most of them gave up TDD. Somehow it didn’t fit their new lives.[L^why]
I want to leave the topic of stickiness for another day. Right now, I’m more concerned about the slow uptake. If I’m even roughly right about my model above, TDD does not, in the early days probably months, deliver much value to its user. Gratification is at best delayed, and between doing it poorly and giving it up, value isn’t there at all.
If we had a way of delivering real value starting right from “where they are”, right up to and beyond TDD, we’d have a much better shot. What might that look like?