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?