jamieb: here's a sequence of thought that explains why I think TDD creates good architecture.
mreiland: angry rant that seems only tangentially related to jamieb's comment
me: I'm going to say jamieb has a sensible opinion on the subject, though I don't entirely agree with him. And I'm going to assume mreiland has had a bad day, but he hasn't said anything that contributes anything to my understanding of the subject, jamieb's comment or discussion in general.
It's only sensible if you don't think too hard on it.
The point is similar to DHH's point, in that a process (in this case TDD) doesn't magically give you good design. Neither does following SOLID, understanding the Law of Demeter, or being aware of the Cyclomatic Complexity of your project.
jamieb thinks TDD results in great design (the conclusion). jamieb then decides to cast around finding a reason why. jamieb comes across a series of completely unrelated things that "makes things more testable", and since they're generally associated with positiveness, concludes that TDD isn't negative.
The conclusion does not follow the rationale. The point is that this is indicative of the sort of thought process that tends to create bad designs.
Rather than trying to push for more developers to be pro/anti-TDD, we need more developers who are simply aware of the decisions they make, and the process they use to come to those decisions. That will have a far larger effect than any amount of TDD ever will.
mreiland: angry rant that seems only tangentially related to jamieb's comment
me: I'm going to say jamieb has a sensible opinion on the subject, though I don't entirely agree with him. And I'm going to assume mreiland has had a bad day, but he hasn't said anything that contributes anything to my understanding of the subject, jamieb's comment or discussion in general.