The burden of proof usually lies on the person suggesting a change to an existing process. What arguments would you give to try to convince someone to do TDD? Because arguments against can be really simple and reasonable: "it's a risky change that will slow us down without obvious upsides", "we don't like to change, it's effortful, and stressful", "we don't have the skills to do it" etc. And that can be told of ANY change of any process/routine!

So what would you say to a team of developers if you wanted to persuade them to do TDD? (or to a manager who has influence on them)

> I do not like broccoli. And I haven't liked it since I was a little kid and my mother made me eat it. And I'm President of the United States and I'm not going to eat any more broccoli.

Some people just don't like broccoli. You can force them to eat it, but they'll end up resenting you.

What's wrong in doing things the way you are comfortable doing?

It leads to lots of brittle and highly coupled tests?

It always focuses on the next immediate task which leads to going down a lot of dead ends, and a lot of local optimums that need to be refactored out?

The key benefit is that it helps you focus, even when tired or stressed. You get dozens of small wins/celebrations every hour which is great for your motivation. It also ensures you actually write tests (again handy with tight deadlines and high stress situations).

Does that make it worthwhile? Sometimes. I did a TDD exclusively when I had young kids and it was a great help with my focus. I'd recommend it to new parents, people with sleeping disorders, people in high stress work places, etc.