I would humbly suggest that because you and parent (and other people here) have such a different positive experience with TDD, that you cannot quite agree when it works, only that it sometimes works, then this is a big indication that TDD is just a placebo.

But maybe that's what's needed - a placebo to feel you better as a programmer, and thus making you more productive through your feelings.

> TDD is just a placebo

This is my experience. I've watched teams do TDD, only to come up against their first refactor and have to change 80% or more of the tests. Just the other day, they were griping about a code review that they had to do which involved changes to 2,000 lines of test code over a code change with minimal functionality change.

TDD has the effect of making you think differently about how you code. Thinking about how you write code is a good thing, but you don't need TDD to make you think differently about your code. You just need to think.

I can't speak for the other person, but from my reading, we don't actually have very different experiences. We seem to agree on the value of testing of large/complex project, but have a (minor) difference of opinion over the value of testing in very small projects. Indeed, I'm pretty sure we're deep into hair-splitting territory, as I do agree that TDD'ing small projects can lead to better code, I just don't think the pay off is as obviously big as it is for more complex ones.

It's like observing two fans debate which Star Wars movie is the best and the merits of Jar Jar Binks, and concluding that because they disagree, in fact all Star Wars movies must be pretty bad.

> and concluding that because they disagree, in fact all Star Wars movies must be pretty bad

No, I am not concluding that the TDD is bad, if anything, I am concluding that it doesn't actually matter. Anyway, I am not even clearly doing that, I just wanted to entertain the idea that some practices (such as TDD) can be placebo, so they subjectively feel as a good thing despite the fact that we cannot measure any effect.

Neither was my intent to touch the moral issue about placebos.. I think if it works for you, do it.

In fact, thinking about it some more, there can even be practices in SW development that have nocebo effect, that is, have no measurable impact, but make you feel worse. Daily scrum meeting comes to mind for me.

I have the same positive experience as both of the above commenters. I've found that there are many other variables which can change its effectiveness though:

* The type of code I'm working on

* How well I remember/understand the full requirements.

* How much of the testing framework is built already and how much I have to build.

* The type of test I'm writing.

* How new the project is.

Yes, TDD seems to involve having a decent idea of the requirements (very un-agile). Many projects are making it up as they go along and iterating to a reasonably correct outcome.

It means having a clear idea about the requirement you're implementing at that point in time (not un-agile). It doesn't mean that you have to create a big set of requirements up front (un-agile). You can just pick a story, convert it into a test and implement the code, rinse and repeat.

Writing the test also gives you a second chance to think deeply about the requirement and fix any problems with it before wasting time implementing the wrong thing.

To me it's sort of like people who use an index card when they read. They move it line-by-line down the page so their eyes have an easier time traversing the line of text.

If this is the crutch that makes you a better programmer, who am I to discredit the practice? But dogma has no place in software engineering.

Kind of like those developers who have to rely on syntax highlighting and linters, right? Those guys! :)

Sometimes using something to help you write better code is just a plain old good idea. You can write it off as unnecessary dogma, but if it actually makes your code better you're shooting yourself in the foot a bit.

> Consequently writing tests, even if you never actually run them, makes your software better.

It could be argued that an experienced programmer doesn't need TDD to write the same code that TDD could have produced.

That used to be my attitude too.

However the experienced programmer will be very happy when they don't have to re-test all of the old functionality manually after a large re-factor of some core code.

Experienced programmer may write tests after the main code is complete to make sure nothing is broken during refactoring. It has nothing to do with TDD.

That's true. Neither from system design, nor from quality perspective TDD is necessary to produce good code. However, it may still add some value even for experienced programmers, when it's easier to write a test than to build the pure mental model of the domain or the algorithm.

I've only been a developer for 20 years so I'm not at that point yet.