Rumbling about Test Driven Development

I’ve been talking about Test Driven Development(TDD) practices in the past, but I didn’t give my opinion on that.

Unfortunately, I am not a big proponent of TDD.

It’s probably because I haven’t worked in places where it’s been a serious part of the culture, haven’t seen how it can work, and haven’t found the motivation to rearrange my thinking accordingly.

Typically, with TDD, I do very simple things like transformation functions, validations, and so on, where the result is very deterministic and easy to code in tests. For more complicated things, I first make application design — draw components and try to fit them into concepts I understand, because complicated things don’t sink into my head immediately without visualization. And questions often pop up. The most common one — is it even possible to do what I want to do, and when I get the answer to that question, there is a good chance that some part of the code has been already written.

From my personal experience, I’ve noticed that my greatest productivity in development has most to do with the clarity of the task. I always do not make the most complex or highest priority tasks first, but the simplest and most understandable ones. Even if they are large is size. I believe that this is the one of the greatest bottlenecks in the software engineering…