Test Driven Development
It's hard to argue against TDD because that is often construed as arguing against software testing itself.
I guess there are actually people who think that all testing is bollocks, but I am not one of them. I think that there's value in regression and acceptance testing. Yet I still think that TDD is absolutely the wrong way to go. I'll try and explain that opinion.
I will try and not bring up any arguments that boil down to "if you're being stupid, TDD doesn't help". Sometimes people claim that TDD makes software development easier. But "easy" is a big concept and I assume they don't mean "follow that one weird trick and your programs will always work". Nobody can expect any software development technique to help so much that you can switch your brain off - and I don't expected that from TDD.
The object of TDD is the unit, and the unit test. That is not necessarily always true, one could theoretically do test driven development against higher-level functional tests. But since one of the claims pro TDD is that it makes the code itself better, and since we write programs by typing in one unit of code after another (roughly), I think it's fair to say that the unit is the canonical choice for TDD.
So TDD starts out with a simple test. That test fails, so then there's code being written to satisfy the test. Then add another test and so on.
The usual claim is that, by going by that method, you're going to end up with a testable (hence well-designed), and well-tested unit of code.
In my opinion there are a few things wrong with that claim.
First, testable does not equal well-designed. In fact, testability and well-designed-ness of code are completely orthogonal. Yes, an easily unit-testable class is probably better than the same class with a design that prohibits unit-testing. But it's only exactly that.