Developer Blog

  • Blog
  • /
  • Test Driven Development may not be right for you. A short trip to developer psychology.
By Dracony on 28 January 2014

Before I start this, let me emphasize on that I’m going to be talking about Test Driven Development specifically and not Unit Testing in general. For some reason people confuse not following TDD with not writing tests at all, so this little disclaimer should take care of angry comments.

Now let me take you on a whole new route, we’ll dabble in some psychology a bit, specifically Jungian theories. One thing he is definitely famous for is describing sets of psychological types, that may be used to classify human behaviour. One of such classifications concerns with our preferences when making decisions and basically defines which route we take when solving problems. It is represented by two dualities, Thinking vs Feeling and Sensing vs Intiition.

types

Here are some brief examples:

  • Thinking – deciding which phone to buy by comparing specs.
  • Feeling – deciding not to accept the job offer because of getting a bad vibe from the HR.

  • Sensing – tasting food, following defined steps.

  • Intiuition – feeling the taste of the cake in your mouth just by looking at its picture, trying to find a larger picture.

This also divides people into rational and arational types. Arational differs from irrational because irrational implies that a particular judgement has been made against common sense, while arational means that a something else has been used instead of rationality.

Now a lot of the science/tech guys would find themselves as to being rational people, and it usually is so. A lot of the developers I know are of the Thinking/Sensing type and they hold the majority when it comes to defining methodologies.

And that is how TDD was born. It’s a step-by-step process of first coming up with general architecture, then writing tests for it and then implementing it. you have to have a pretty clear vision of what you are building to get this to work for you and it rewards you with 100% test coverage at the end. This is great, but…

…it definitely sucks for me. Whenever I think I have architecture figured out, I find myself scratching it after about an hour into implementing it. I’m actually more productive when I start writing a random class in the middle of the soon-to-be application trying to get a feel of what services and features I will need. Then being half done with that class, I forget about it and immediately move to some other one, trying to get more clues about what would be the best class hierarchy. Sort of like when playing minesweeper you start by uncovering random squares to get a nice feel of your surroundings. and when I’m at 90% with being done with everything, sometimes an awesome idea comes to my mind but it requires me to rewrite 30% completely.

Now how would I couple this with TDD? I tried it, and all that came from it was me writing tests for classes that won’t even be there in the final release. So I decided to stick to the good old style of writing tests after I’m 100% sure that a class won’t change later on, e.g. after it’s done.

I guess at this point I betrayed myself to be of the Feeling/Intuition type =) And that is the point of my post here. Different people require different methodologies , – so don’t feel bad if some methodology doesn’t work well for you, as it may just be that it goes against the way your brain operates. Developers who are in charge of their teams should definitely keep this in mind. Because forcing a logical approach to intuitive people is as much a fallacy as teaching left-handed children right-handed writing. Now that i think of it it seems to be that Intuitive people prefer to work alone and usually become freelancers, since it gives them more perceived freedom than a company worker feels.

P.S. Don’t be lazy, write tests, they help, a lot.

comments powered by Disqus