Are you still sceptical about TDD?

I'd like to challenge your beliefs and assumptions by sharing the 8 common fallacies about TDD.

Firstly, how are fallacies formed in our heads? Fallacies (incorrect beliefs) are formed in our heads because of how we infer information.

Given the amount of information that we consume, human brains have evolved to filter a lot of information out to make an inference and jump to conclusions, the fallacies.

Some of you have decided to try the 'interruptible workflow' technique I shared, that's great!

I thought it'll be useful to share some evidence I found, and further information shared by others to reinforce your attempt:

https://twitter.com/ceilfors/status/1583397713357307904

First, some evidence.

There is a paper published in 2018 that studies the technique we have covered!

Although anecdotal, there are replies in the thread from others who've been practising this technique, even from 35 years ago!

pubsonline.informs.org/doi/epdf/10.12…

Do you struggle to code after a meeting? In the morning? Do you struggle to pay attention to a meeting after a deep work?

We know that context switching is costly but we rarely talk about how we can be more interruptable.

Here's a simple interruptible workflow that you can try: When we are getting interrupted a lot, our natural reaction is to try to reduce the number of meetings.

Unfortunately, we can't entirely eliminate meetings therefore I'm not going to talk about optimising meetings, but rather optimising our workflow.

Great communication skill is essential in making an optimal technical decision.

Behaviour-Driven Development (BDD) is a tool that can help teams communicate better.

Let me tell you a short fiction about how BDD helped a team succeed: In the beginning, there was a team who were building a product that will make millions of pounds.

Let's call that team Granola, because who doesn't like good old granola?

They struggle to deliver as the product should submit data to the legacy system at the backend.

Many of the software engineers I talked to told me that they practice TDD out of guilt.

That's not right, we need a different way to think about TDD.

I've been practising TDD for almost a decade, here's how I currently think about it: Current literature focuses on how TDD is the best design technique out there, therefore we have to adopt it.

But, I don't use a hammer merely because it's the best tool to drive nails, it's also because I can't drive nails without a tool.

Let's try that angle instead.

Smaller commits help retain my flow state, therefore improving my productivity.

To have smaller commits, you have to be able to slice your task into nano-slices. I have found adopting Angular's commit format to be helpful in the slicing activity. The part of the commit format that helps me slice my work is the definition of commit types.

You don't have to remember all of the commit types to start with. In day-to-day development, I'd only use four of them: feat, fix, test, and refactor commit types.