Making a Nice Cup of TDD
Test-first, or tea-first? Is the sequence of steps within a task merely a matter of preference?
A couple of weeks ago,
tweeted this:When did TDD become an identity? "I'm not a TDD person"--I heard this the other day. đ It's not a genetic disposition, like cilantro tasting like soap. How did this happen? What can we do now?
Intrigued by Kentâs last question, I am writing this essay hoping to change at least one mind. Therefore, If youâre ânot a TDD personâ, read on.
The view of âIâm not a TDD personâ usually concludes that Test-Driven Development (TDD) is a matter of individualsâ preferences, which I've noticed in various discussions, responses to tweets, and even some TDD threads Iâve written. Further, this view is typically shared against one single aspect of TDD. That is, it doesnât matter whether a developer is doing the test-first or the test-after approach. The sequence of steps in a task doesnât matter, because itâll produce the same result.
After all, the sequence of steps in our daily life doesnât usually matter. When youâre making a cup of tea, whether you put in the milk or tea first, the result is the same cup of tea. Is it the same cup of tea, though?
I grew up in Indonesia. In Indonesia, the most common way I used to drink tea is to take it plain, or with sugar. We donât drink tea with milk in Indonesia, at least not commonly.
I moved to the UK nine years ago, and apparently, tea with milk is the default for my British friends. A friend of mine, George, came to my house one day. Immersing myself in the British culture best I could, I offered him a cup of tea. He said, âYes, please, with milk.â Believe it or not, Iâve been practising making tea with milk. Simple enough, mix milk, a tea bag, and hot water, and Iâm done.
George took a sip, his face cringed, disgusted, disapproving. Being polite, he didnât say anything, until I asked if I had made the tea wrong. âIt doesnât taste right. Could you explain to me how you made it, please?â George asked politely. I explained to him that I took a cup, poured some milk into it, and then he interrupted me. âStop, what? Thatâs not how you make a cup of tea! You put in the tea first, the milk last!â
This argument about how steps should be sequenced reminded me of TDD. So I got curious and asked him to come into the kitchen with me and show me all the steps heâd do, and with a big sigh, he agreed.
We entered the kitchen. I grabbed a cup, and to my surprise, George already interjected on this first step. He said, âWrong, turn on your kettle first, then only ready the cup, tea bags, and milk. Itâll save you some time.â So I turned on my kettle, another interjection, âWrong, youâre using too much water, youâre wasting your electricity, why did you make it too full?â All the minuscule, seemingly small things that I donât quite care about, he commented on, until we reached the point where the water boiled. We now have to make a hard decision. Tea-first or milk-first?
George, being an expert in tea-making, explained to me, âTea first because if you put the milk first, the boiling waterâs temperature will drop quickly, leaving less time for the tea leaves to brew.â
It makes a lot of sense, I thought. As I poured the boiling water into the cup, my cup began to crack. I was shocked. Calmly, George said, âWell, if you want to enjoy a perfect cup of tea, you need a better cup!â Annoying, but I finally managed to make a cup of tea following his method.
It did taste nicer.
In this seemingly simple task of making a cup of tea, the tiniest detail I hadnât considered made an impact. When you zoom in on a specific task, youâll discover that the sequence of steps to complete that task does make a difference. Similarly, when you zoom in closely at software development practices, the sequence of steps you execute can make a difference.
When I adopted the kettle-first approach and the tea-first approach, I saved time and made a better-tasting tea! In software development, test-first or test-after will make a difference. When I practice TDD, Iâm more productive and produce better-quality software. There is evidence that others have gained similar results. (Iâll expand on this thought in my next post).
Perhaps the question is, how much of this optimisation is worth doing? Maybe TDD only improves our productivity and quality by 1%. Whatâs the point of changing a habit to get a 1% improvement? It may seem too marginal to change your âpreferencesâ.
But most of us struggle to grasp the power of tiny continuous improvements. A 1% improvement may seem marginal, but do it every day for one year you will improve 37x! Better yet, once you adopt it as a default, you donât need to think about making improvements because that new habit of the sequence we tweaked is already making those improvements.
Like most practices, TDD is not context-free. My cup broke when I tried the tea-first approach for the first time. If youâre a TDD practitioner, help others feel safe by remembering that context matters. Otherwise, you may be breaking lots of cups!
So does changing the sequence of steps matter at all? Consider what my wife told me as I write this essay, âWhen I cook an omelette, you can choose to put egg first or oil first in the pan. The sequence is obvious if you want a better-tasting omelette!â It becomes apparent that the sequence of steps in which we do things, whether in tea-making, software development, or cooking, can indeed yield significant differences in the result.
Quantum Steps exists to transform our approach to work for the better. If you discovered something new or love what youâve read, please do me a favour, and share this post with your friends. Thank you.



Hey Wisen! Ben here,
With regards to the unintuitive nature of compounding returns over a long period of time, I wanted to understand better how we advanced our society so quickly and why it appears to be going faster day by day.
With regards to investing, the current human lifespan is just out of reach from truly seeing the absurd affects first hand of continuously small compounding over long periods of time.
This is the avg annual returns at 100-500 years with 3% CAGR compound annual growth rate
19.21863% (100 years)
184.67790%
2366.17116%
34105.92955%
524375.44683% (500 years)
542K% is absurd.
However, I think this might be slightly flawed.
"But most of us struggle to grasp the power of tiny continuous improvements. A 1% improvement may seem marginal, but do it every day for one year you will improve 37x!"
This assumes that you continually make 1% improvements every single day (1% better than the previous day). I think it's actually linear. You save 1% of your days time every day, but you aren't 1% better than the previous day). At the end of the year, given that you do this 365 days a year, you will save 3.65 days worth of time.
maybe more if you take that 1% of time savings each day and try to increase your productivity further.
Given all this, I think TDD saves me more than 1% in productivity :)
Looking at the software engineering space and what is published, there always seems to be âsomethingâ that is âdriving developmentâ.
TDD = Test Driven Development
BDD = Behavior Driven Development
DDD = Domain Driven Development
etc
All of these encode an intent with which software development proceeds. And that, IMO, generates the critical question: What is the most beneficial way for me to provide direction and momentum to the work I am doing?