Psychological safety and dopamine may explain TDD's low adoption
Today’s Crafting Tech Teams issue is all about how psychological safety and dopamine can help you better understand TDD adoption and its underlying benefits without engaging into the usual controversy and resistance. I promised a survey yesterday, but it’s going to land later this week. Slight improvements needed.
🔒 The last few chapters of this article are previews from the updated No-nonsense TDD Booklet (rev3). If you’re a paid subscribers, you’ll have early access to these today. I’d love your feedback as I’m continuously distilling and improving the booklet. These are limited as a preview for paid subscribers and will go public (free) at later date. We’ll cover the following:
Dopamine, effort and discipline. Is TDD working hard or working smart?
TDD sees mixed opinions, reasonable usage reports but lower actual usage. Are we missing something?
🔒Testability and automation match your team’s willingness to look at their mistakes. Mandated test coverage is a poison pill for many development teams.
🔒TDD is about interruption planning. Maintenance and DevOps processes that I have seen only adopted by high performance teams who use TDD. But is it useful to your team?
Dopamine, effort and discipline
Gamification is a strong loop in our overall effort, reward and anticipation chemistry. These tiny details underpin the satisfaction behind:
green checkmarks of passing tests
a successful build
the bling sound upon payment on your phone
This is the core of good UX. Having clear, fast and accurate feedback is the hallmark of software crafting discipline since the invention of compiler errors.
However, it’s no fun to build the compiler yourself. And to many developer that I’ve interview about TDD—that’s what it feels like to them.
“I have to build the thing that helps me build the thing…”
“If I build it first instead, I can just use my working code as a safety harness for new tests”
This second quote is often where the problems start.
You see—engineering teams have tendency to overvalue coverage and green tests, and undervalue the error message when something fails and coverage and mutation density around critical paths. This is skewed value structure manifests when teams value quantity and coverage of tests over quality and accuracy.
The coverage gives you the immediate dopamine. It’s covered. It passes. Next.
However, it’s the investment into the quality of tests that produces the focus on the discipline and long-term benefits. The common response to this is, “But Denis, my team can get all the benefits without the pain of TDD.”
Or so they claim. I could be wrong. I like TDD. I find it difficult to hide my bias. That’s why the survey is late, I’m getting some professional advice.
TDD sees mixed opinions, reasonable reports but lower actual usage
Jason Gorman reminded me of an important clue about TDD when teams talk about it. There is a general confusion on what it is. And an even bigger disagreement as to what you need to do to claim you are.
In our podcast episode he cited there are far fewer teams that practice TDD properly and earnestly compared to reports. There are several studies on this.
I’ve been going through research this weekend and stumbled upon Laurie Williams’ work. A 2003 study highlighted the increased value TDD provides to the external code quality and design simplicity compared to traditional methods. Again—it’s not about the tests. It’s about the testability and simplicity about what it is you are testing that TDD improves.
The second benefit is the ability to have full trust in the manner in which the tests fail. You see them failing as a precondition to implementation. This provides a high level of trust and verification for it testing the right thing. However, the ability to test at the right level of abstraction and interface detail is still up to the developer.
Though recent advances in practical DDD and code smell automation by use of AI has definitely improved matters, it continues to be a pain point for many practitioners (TDD, test-first or otherwise).
You don’t need coaching for it though. There are many resources and a few different flavours of it even. Here’s a list of other content creates you can seek for inspiration for a large compendium of courses and tutorials. I’m sure you’ll find the one that fits you best:
Remember, the goal is not to engage in the tug-of-war between TDD's enthusiasts and critics but to embark gaining more understanding and improving our own and the overall craft quality of our industry.
🔒Testability and automation match your team’s willingness to look at their mistakes
Mandating test coverage can be a double-edged sword that might stifle rather than encourage quality. Ask yourself—what would your teams or coworkers do in absence of mandates and incentives. Would they naturally adopt TDD? Would they stop testing altogether?
What is the default culture?
An environment where that default culture is suppressed can quickly devolve into a lack of psychological safety. After all, the best ideas should prevail. When ideas cannot be safely challenged or when speaking up, risking being wrong comes with judgement and inter-personal risk the culture defaults rapidly to docile, passive behavior. You ask tough questions. You get silence.
I often witness this with teams during coaching efforts:
Unanimous agreement that testing could be improved
Little wiggle room to actually invest time into doing so
When preparing an action plan to make improvements, ”nothing right now” is the most common answer.
I start coaching teams by overcoming that last part. Human nature is tricky, but in this case it is sadly quite predictable and justified:
In an environment where making mistakes is unpleasant, you don’t want an automation telling you how much of it you are doing on a daily basis. Especially when you have to invest thought, effort and creativity into shaping that automation.
So if not there, where shall we start? I suggest teams always start at two areas:
Improve triage of their busiest process—something that keeps their calendar and cognitive capacity overloaded
Psychological safety—embrace learning
🔒TDD is about interruption planning
TDD extends beyond the realm of writing tests. One aspect we already discussed is external quality and simplicity of design. Let’s be clear—it’s still the developer who performs this design. TDD simply gives healthy incentives, similar to how you usually click the first google search result.
However, there is a deeper aspect to TDD that only avid readers of both the books Clean Code and Test-driven Development may recall. Iteration time. Specifically, how much time you spend from green-to-green. When done rigorously, especially in an ensemble or pair, engineers will spend somewhere between 5-25 minutes in an unfinished state. This comes with several benefits:
Steps are very small, allowing for rapid, natural discussions
Interruptions do not cause a large context switch
Undos are small, enabling quick course correction and experimentation
Natural fit for Trunk-based development, allowing branchless commits with each green phase