I don't have complicated feelings towards TDD at all.
It has a good idea but as many others have said, you need a pretty well spec'ed software beforehand for it to work. When you code a certain piece you might change it, top to bottom, several times -- we aren't perfectly thinking machines and we need to iterate. Having to re-prototype tests every time hurts productivity not only in terms of hours -- an obstacle that can be overcame in a positive environment and is rarely a true problem. It hurts in terms of it demotivating you and you losing the creative energy you wanted to devote to solving the problem.
The "it depends" thing will always be true. When you gather enough experience you will intuitively know the right approach to prototyping + testing an idea.
TDD is but one tool in a huge toolbox. Don't become religious over it.
I liked part of Kent Beck's writings back in the day but I am inclined to agree with other posters that he mostly wrote books to sell courses. I mean the book had good content, don't get me wrong, but they also didn't teach you much except "don't do waterfall".
Martin Fowler also wrote some gems, especially "Refactoring", but in the end he too just tried to enrich your toolbox -- for which I am grateful.
Ultimately, do just that: enrich your toolbox. Don't over-fixate on one solution. There is not one universal solution, at least we don't know it yet. Probably one day a mix of mathematical notation + a programming language will converge into one and we won't ever need another notation again but sadly none of us will live to see it.
It has a good idea but as many others have said, you need a pretty well spec'ed software beforehand for it to work. When you code a certain piece you might change it, top to bottom, several times -- we aren't perfectly thinking machines and we need to iterate. Having to re-prototype tests every time hurts productivity not only in terms of hours -- an obstacle that can be overcame in a positive environment and is rarely a true problem. It hurts in terms of it demotivating you and you losing the creative energy you wanted to devote to solving the problem.
The "it depends" thing will always be true. When you gather enough experience you will intuitively know the right approach to prototyping + testing an idea.
TDD is but one tool in a huge toolbox. Don't become religious over it.
I liked part of Kent Beck's writings back in the day but I am inclined to agree with other posters that he mostly wrote books to sell courses. I mean the book had good content, don't get me wrong, but they also didn't teach you much except "don't do waterfall".
Martin Fowler also wrote some gems, especially "Refactoring", but in the end he too just tried to enrich your toolbox -- for which I am grateful.
Ultimately, do just that: enrich your toolbox. Don't over-fixate on one solution. There is not one universal solution, at least we don't know it yet. Probably one day a mix of mathematical notation + a programming language will converge into one and we won't ever need another notation again but sadly none of us will live to see it.