TDD is unintuitive. Does it matter?
How our intuition may not be as reliable as it seems.
Welcome to the latest issue of my newsletter series, ‘Test First vs Last’, where we’ll explore how the sequence of writing tests affects our minds. The full context of this series can be found in the introduction post.
Test-Driven Development (TDD) is often rejected due to its perceived unintuitiveness. Given the seemingly unintuitive nature of TDD, some people have seen me as unethical, manipulative, or forceful in writing about TDD’s benefits. While I question being labelled as unethical, manipulative, or forceful, I do agree that TDD is unintuitive.
In this essay, I’ll explain why TDD may feel unintuitive, and concurrently, challenge the reliability of our intuition.
Tests are intuitively after the fact
We don’t have to look far to understand why TDD is unintuitive. Tests are traditionally conducted after the fact, and we would intuitively understand this. If there’s no code has been written, what is there to test?
The idea of test to be after the fact is simple enough for even young children to grasp. They are tested, once they have studied. They got tested for an illness, once there’s a symptom for it. They can test a dish, once it’s started cooking. Testing, always comes last, not first!
Intuition serves as our subconscious navigator, built from our past experience and knowledge, allowing us to interact with our environment without conscious reasoning. We don’t need conscious reasoning to realize that testing has traditionally come last.
However, TDD challenges this traditional sequence. If it’s seemingly unnatural or unintuitive, does that inherently make TDD an ineffective technique?
Unintuitive? Does not make it wrong
The foundational argument against TDD here seems to be its lack of intuitiveness, concluding that what is unintuitive is not effective. If there’s a more intuitive way of doing things, why change?
Observing the daily routines of my 7-year-old, it’s evident that not all effective practices are intuitive. Would she grow up to brush her teeth regularly, naturally, by her intuition? This habit is not instinctively formed. It’s been cultivated and reinforced.
Similarly, the notion of the Earth being spherical is not immediately intuitive. How does our Earth look like the Blue Marble (a picture only taken 50 years ago)? To our ancestors, and to anyone climbing high, the world appears flat, contradicting the actual spherical model.
Another example is riding a bicycle. It’s widely appreciated, but it’s not something one can intuitively do. It requires learning and practice. It appears that not everything unintuitive is inherently disadvantageous.
Fosbury’s unintuitive gold medal
TDD is unintuitive as it needs us to reorder our work sequence. This simple alteration can yield superior results, analogous to Dick Fosbury’s revolutionary high jump technique.
The aim of the high jump is straightforward: to leap as high as possible without knocking the bar over. Before Fosbury, athletes embraced techniques that had them facing down and leading with their legs. Fosbury, however, flipped this traditional technique by facing up and leading with his head.
The initial scepticism around his technique, due to its unintuitiveness, diminished when he won the Olympic gold medal in 1968. This unintuitive technique, the Fosbury Flop, is now becoming the norm.
The Fosbury Flop circumvents our biological limit by shifting our centre of gravity, allowing us to jump higher with the same amount of force. I believe that we can apply the same principle to knowledge workers, and one technique that we have uncovered is TDD.
What biological limits are we circumventing in TDD? Read the essays in this series and Why TDD Enhances Developer Productivity.
The illusion of intuition
The daily routines, understanding of the Earth, and sports exemplify how unreliable our intuition is. Comparing these examples, one major difference in developing software is how much more involved our minds are. Could intuition be more reliable, perhaps in our line of work?
The Invisible Gorilla, a book by Chabris and Simons, argues against the excessive reliance on intuition, highlighting the numerous biases and limitations inherent in human cognition. One illusion discussed in the book is the illusion of attention, which I observe to be affecting us software engineers to overlook our work.
To understand this illusion, watch the following video and follow its instructions.
Did you watch the video? In the original study, 50% of participants did not report seeing the gorilla. If you did watch the video, I bet you noticed the gorilla, that’s because you expected some sort of an illusion when you watched it!
As software engineers, our minds constantly fall prey to this illusion. We can’t notice the gorillas in our work. We tend not to notice things that we don’t expect, here are a few examples from this series:
We don’t expect false positive test results
We don’t expect tickets to be that complicated
Software engineering is not the only profession that’s affected by the illusion of attention. In the healthcare industry, even experienced doctors can misdiagnose an illness. Similar to TDD, a structured approach, such as having a checklist, has been proven effective in improving patient care.
One might wonder why Dr. Atul Gawande chose to write the book Checklist Manifesto. My guess? Checklists are unintuitive.
Conclusion
TDD, while seemingly unintuitive, doesn’t mean it’s a technique to be dismissed. Numerous examples illustrate how unintuitive methods can prove effective. TDD effectiveness is independent of its unintuitiveness.
In my subsequent essay, I’ll propose how to make TDD more intuitive for us software engineers. Stay tuned.
In my experience, it's not the fact that TDD is "unintuitive" that prevents people from doing it, it's that folks generally don't like to do things differently (especially if they've become competent or expert, and become a novice again) unless there's a compelling reason to do so. TDD is not a "quick win" where we can easily demonstrate its superiority.
Learning to ride a bicycle might be hard because it's unintuitive (though I don't think intuition is a useful term for that kind of learning as it relates to biologically primary learning), people try it and learn how to do it anyway because they _want_ to.
I'd also say that automated developer tests (first or last) are probably not "intuitive" to many, as they often didn't learn to write tests until after they were already capable of coding. So learning to write tests at all (instead of manually testing or sitting in the debugger) is unintuitive for them.
btw, I don't see the "test after" intuition coming from medical or cooking (it's an interesting analogy, but not one I have ever heard before). I see it as "that's how I've always done it", and it generally "works for me", and therefore it becomes part of their expertise (and then perhaps their identity).
Well written article. I like it. There is also another angle one can take though, that my be easier for some to digest.
When we test something, or rather check something (the test is really just an automated checker), we need to know what we’re checking for. TDD is a way to define what we’re check for up front, in small incremental steps. In other words, it’s about defining what the code should do before we create the code that does it. From that viewpoint it may feel a bit more natural.