Thanks for the comment. I'm the author of the original article. I was surprised to find this old piece on the HN front page today.
With all respect, I don't misunderstand TDD or OOP. I agree that those aren't methodologies in the strict sense. But rigid adherence to OOP design or TDD can paralyze a team and focus development on goals that aren't the customer's priorities. OOP and TDD can influence how the team works and what shape the project takes just as much as waterfall or agile. When I read articles claiming that TDD is the sure path to reliable development, that's a methodological claim, not a technical practice.
I think we're really in "violent agreement" here. Rigid adherence to these "things" (not necessarily methodologies) never work. The benefits of what these "things" offer, to the degree that they are understood by the practitioners, are real. But they are often (perhaps categorically) misunderstood, applied haplessly and held to claims they never made in the first place.
What I have seen work is methodologies adopted to get the benefits of what the methodology actually delivers. Not a checkbox so say "we are X".