Elephant, TDD and me
Whether you think you can, or you think you can’t–you’re right
– Henry Ford
In this blog post, I would like to share my experience of transition from the TDD-sceptic to the TDD supporter. It is not about convincing you to use TDD. There is no chance I’ll do it better than Uncle Bob. Instead, it is about transition itself. It could be a very unpleasant, and I believe it when the most of the people give up. My transition was not an exception. It was long, painful, and full of ‘burn it all in hell!’ moments.
It started when I joined Unity Technologies in 2013. At that moment, I was very skeptical about TDD. In particular, I didn’t like the fanaticism of people who preach it. For me, fanaticism is always a bad sign, so I was never taking it too seriously. This stupid and quick judgment kept me apart from the beautiful and rational part of TDD.
As a sign of respect to my colleagues, I decided to give TDD a serious try. It was as hard as hell to apply a new technique while I was trying to get some valuable work done to prove my bosses and colleagues, that they’ve made a right choice by hiring me.
After a couple of months, I started to notice some of the TDD benefits myself: less time spent in the debugger, regressions catching, shorter iterations, and so on. But, for some reason, I was still feeling worried. My head was accepting arguments, supporting TDD, but my heart was not. Why is that?
2 Books helped me to understand why.
The 1st book is called Switch: How to Change Things When Change is Hard. In this book, Dan Heath refers to the “Rider and Elephant” model. Rider represents our small, rational, logical, and controlled sides. The elephant represents the emotional side, which is big, irrational, and automatic. Rider tends to think that he is a boss, and the elephant is just an obedient animal. Because of this delusion, the rider often finds himself, following the elephant’s favorite track: ignoring sports exercises, eating sweets, drinking too much coffee, and not writing the tests.
The 2nd book is called Your Brain at Work by David Rock (one of the best books I’ve read in my life). According to this book, the fundamental rule, lying in the foundation of all brain processes, sounds like “minimize danger, maximize reward.” The certainty reduces danger (the known path for the elephant). Your brain loves it.
Writing the tests was not only something new for me, but it was also a question of changing the habit. Therefore, there was a lot of uncertainty around it. My mental voices were telling me the following:
Tests prove nothing. Only the working prototype shows it can work!
Stop writing more tests! It is a waste of time! Do some real work instead!
You know how to do it without the tests.
These were irrational voices. It was relatively easy to shut them up. But, there were a bunch of very reasonable doubts.
New language, framework, or tool. Suppose you are going to build a system using a new, super-modern framework. Despite the fact that framework exposes good testing capability, it feels uncomfortable to start learning it using a not-yet-mastered skill.
Uncertainty = skill uncertainty * new tool uncertainty
System integration. The classic example is a file system. How do you write tests if your program saves the right artifacts at the right places? Should I create a testable file system abstraction? Should it be an integration test that creates files on disks or just pure unit tests? There are too many questions, compromises, and decisions to make.
Uncertainty = skill uncertainty + decision making uncertainty
Legacy code. A lof of the code you deal with is a legacy code (without any tests). Should I do it testable or just leave it as it is? Maybe some parts of it? It’s pretty much the same feeling as from system integration.
Each of these three situations deserves a book. I’ll share my experience in how to deal with some of them in following blog posts.
An attempt to use a new and not yet matured skill is perceived as ‘danger.’ As a result, the rider is exhausted, and the elephant tends to turn to the familiar ‘write & debug’ road. From this perspective, one working prototype looks more rewarding than 150 green tests and 0 working prototypes.
Thanks to wise advices from colleagues, I didn’t give up. And after some time, I started to feel comfortable with tests. It just came naturally and gradually. The elephant finally learned the new path.
What also helped on the way is to listen and respect my elephant. It is a part of me and deserves care and attention. This care can be expressed in a variety of forms. You can make it easier for the elephant to follow any path. For example, this helped my elephant to feel better multiple times a day and took only 10 minutes to set up. “If you hate it, automate it!” says Roy Osherove.
Another form of respect is to give the elephant what he wants. If he desperately wants a working prototype without the tests, I’ll give it to him! But first I’ll make sure I know what scares the elephant the most and build the prototype around this fear. After the elephant is satisfied, I’ll throw the prototype away and start doing it in TDD style. The important thing is to avoid the temptation to extract some pieces from the recycling bin and re-use them as-is.
Now, after several years of applying TDD, I feel very uncomfortable if I do not write the tests. It is an irreversible transformation. Do I regret my choice? Yes, sometimes. It took me a lot of time to learn how to write maintainable tests and, more importantly, how to build tests I can trust. And still, occasionally, I have this “it takes longer” feeling. But when it happens, I just run my tests, watch them become green and a barely visible smile touches my face.
Chip Heath and Dan Heath: “Switch: How to change things when change is hard”