Hi Hajime,

Thank you so much for your comment. It made me think a lot. I also have noticed that you have responded to some of my other articles as your own posts. Thanks for that, it has been very helpful.

About TDD being stupid or brilliant, you can notice that I was quoting Kent Beck, the one that came up with the TDD idea. May be tools cannot be stupid or brilliant, but we, humans, often classify ideas as stupid or brilliant. In this case, Kent Beck said that it was stupid. It seemed stupid, but it was not, and it had helped countless people to do developments more efficiently. With time, and a lot of practice of TDD, I have discovered that TDD changes so much as we approach programming, that from it raises many benefits that I didn't even think were possible. That is why I do not limited myself to say "It is not stupid", because this small and simple idea has so many good and hard to predict repercussions that I can't find a better word to describe it than brilliant.

On the other hand, unfortunately, there is a part of "holy wars". I already said that "TDD is a controversial topic to discuss", and it is because people stop thinking and discussing, and start taking positions as if the rest were wrong.

I like the analogy to be a tool, although there is no such thing as MS TDD or GNU TDD, disputes resembles a little what I remember from other holy wars like "vi vs emacs". In the case of vi or emacs, they are tools, but how they behave, and how the user experience them, depend on their knowledge and their needs. And I believe that the same happens with TDD, but in a more radical way.

Because TDD does not have a tool that helps you and guides you, each practitioner of TDD has a different technique, and a different way to work. And what I have discovered, by the hard way, is that learning TDD well is hard, really hard, specially when you have already taught to program.

Most of the practice and experience that I have today, come from this article:

It was the approach that helped me to make a mental shift, and create new strategies about how to focus, and face programming.

It might seem strange for you, but I was, in fact, a great detractor of testing at any of their forms. Like Edsger Dijkstra was in the late 60s, I thought that testing was almost useless. I had my story about it here:

But what I try to accomplish, with these articles, is encouraging people to try to fix their bad habits, and open them a door that they did not even know that existed. I want them to have more possibilities, and more opportunities.

It is not like that if you do not use TDD you are a bad programmer, and if you use TDD, you are a good programmer (I had known good and bad programmers in both sides). What I am looking for, and what I am trying to achieve, is giving them the opportunity of choice.

Because at the end, it is not like vi or emacs. If you use emacs, you do not use vi, if you use vi, you do not use emacs. But if you use TDD, you program, and if you program, you program.

So, by rule of thumb, I often suggest do not practice TDD for projects smaller than six months, neither for those that do not have the proper tools to do the kind of testing that TDD needs.

And there is one last thing, I know that TDD is very hard to learn, it requires a lot of practice, and most of the tutorials are faulty. But I would never agree to force anyone to do TDD. Because 1) as Robert C. Martin said, programmers find smart ways to ruin TDD, and 2) as you have said, it is a tool; and because it is a tool, you should not enforce tools, but instead, empower programmers with tools.

So, I can't thank you enough for your comment and your articles!

I like to write stories about how we understand and apply software engineering, and to make us think about what we could improve.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
David Rodenas, Ph. D.

I like to write stories about how we understand and apply software engineering, and to make us think about what we could improve.