TDD is a very strict discipline. As with any other discipline, in the beginning it always feels extremely restricting and counter-productive. And as with any other discipline, if you persevere and stick to it, the initial awkwardness and confusion fades away and the benefits of the discipline start bearing fruit.
It’s the same as with training for a marathon, for example. At first, you cannot run longer distances without hurting and losing your breath. But little by little, if you keep doing your modest exercises every day, you discover that you can run longer and longer distances without losing your breath and without hurting. Before you know it, you find yourself in a situation where you can run tens of kilometres without feeling any discomfort.
TDD is no different. It feels weird at first. Since software development is all about speed (deliver value as soon as possible), doing TDD feels absolutely idiotic in the beginning. Most of us who were trying to learn how to do TDD initially felt that time spent doing TDD would be much, much better spent writing code. It just did not make any sense to waste precious time on writing tests first.
It is in a way similar to how surgeons in the past felt about washing their hands. They were often in a critical situation where patients were in a life threatening state on the operating table, and instead of jumping in and operating on them, they were required to stop and first wash their hands. Their unanimous reaction to that discipline was “Hold on. You can’t be serious?”
Later on, when science discovered microorganisms, everything became much clearer, and the need to wash hands before doing the surgery became obvious.
TDD is still tricky, because we haven’t discovered those ‘microorganisms’ in software which will mandate that we do TDD before writing code.
Another real life example I could offer from personal experience is learning to play the guitar. When I was young I wanted to learn how to play the guitar as fast as those guitar superheros. Naturally, all I was doing while practising guitar is play as fast as I can. With terrible results. My playing sounded stifled, erratic, uneven and forced. Instead of being able to play fast, I played as if I was hyperventilating.
Then I discovered the merit of another discipline — practising really, really slow. It defies logic, and is on the surface counter-intuitive, but it is absolutely true that if your goal is to play guitar very fast, the quickest way to get there is by practising really slow. And by really slow I mean painstakingly slow. Like, idiotically slow. But if you stick to it, it is guaranteed to get you to the point where you are able to play the guitar at blinding speeds.
Same applies to software engineering/development. If you want to deliver software at blinding speeds, the most efficient way to do it is by slowing down and embracing TDD. There isn’t any other discipline in software development that delivers results quicker than TDD. And I’ve tried everything in my 30+ years career as software engineer. Nothing beats TDD.
Of course, if people, upon reading this, give TDD a shot and spend a few hours doing it, they will no doubt find out that spectacular results are not forthcoming. Similarly, if a budding guitar player spends a few hours practising real slow, he or she will get disappointed — those few hours of practice didn’t bear any desired fruits.
No worthy result comes overnight. You get out of it what you put into it. You need some serious woodshedding spent on TDD before you start seeing the results. But the effort and the wait are well worth it. Only those who are prepared to invest months and months of focused, dedicated woodshedding in TDD will arrive at the stage when they start reaping the huge benefits of TDD.
Once you get there, you realize you are at a much higher level of mastery than your colleagues who remain clueless about the benefits of TDD. Ordinary, base software developers who only waste time on writing the shipping code actually spend inordinate amount of time on activities that have nothing to do with writing the lines of shipping code. They do a lot of manual testing, spending hours on varying the configuration and the environmental variables in order to convince themselves that the code they wrote actually works. If we were to average the hours they spend on manually wrangling configuration/test data vs time they spend actually writing code, we will see that the time spent writing code is usually less than 10%. Not very productive, no matter how we look at it.
None of those copious non-productive hours get spent by engineers who have mastered TDD. And that is the reason TDD feels so great — it gives you wings and superpowers that by far exceed anything your talented and amazing non-TDD peers could ever do.