6 ms·

I'm surprised at how much attention this bit of process dogma is getting on HN. This particular argument about the supposed efficacy of TDD depends on people a

I'm surprised at how much attention this bit of process dogma is getting on HN. This particular argument about the supposed efficacy of TDD depends on people accepting the equivalence of the efficiacy of TDD with the efficiacy of surgeons washing hands, just because the blog author says so. Oh horror, how can you challenge my dogma just because I call it a 'discipline' and verbally equate it to surgeons washing hands. Saying something is true doesn't prove it is true whether you call something a 'discipline' or not. Cults are full of such 'disciplines'. Cult members will vouch for them. A better word is 'ritual'. At best such rituals are cargo cult practices. [1] Surgeons washing hands is a practice with empirical, unchallengeable scientific evidence supporting it,while TDD is a dogmatic practice evangelized by software process zealots, with next to no scientific evidence backing it up. Also TDD != testing and TDD != automated testing (though the evangelizers tend to blur the differences. It is easier to argue that you should write tests, than that you should write tests before you write the code, which is a somewhat more shaky assertion. If you can paint your opponents as opposing tests (vs TDD) you have set up an easily knocked down strawman). Programmers have written tests, including automated regression tests for decades without the blind adherence to the 'write a test first, write the code, refactor, repeat' cycle that TDD consists of. Insisting on this as some kind of moral imperative [2] is snake oil, and it is natural that experienced devs push back against religious preaching. The best 'poke holes in the zealotry gently but firmly' writing wrt TDD is at http://www.dalkescientific.com/writings/diary/archive/2009/12/29/problems_with_tdd.html http://www.dalkescientific.com/writings/diary/archive/2009/1... . Bob Martin's TDD 'kata' is dealt with there in some detail. The comment thread at http://dalkescientific.blogspot.in/2009/12/problems-with-tdd.html http://dalkescientific.blogspot.in/2009/12/problems-with-tdd... is hilarious too, with some familiar names popping up. [1] http://en.wikipedia.org/wiki/Cargo_cult http://en.wikipedia.org/wiki/Cargo_cult [2] The author says as much here http://news.ycombinator.com/item?id=5331108 http://news.ycombinator.com/item?id=5331108 " [TDD] allowed us to go fast, and _keep_ going fast because the code stayed clean. I have come to view it as a moral imperative. No project team should ever lose control of their code; and any slowdown represents that loss of control."

doktrin 14y ago
This reaction is a bit visceral, and unnecessarily so. The "cult" and "dogma" accusations sound fairly outlandish, to be honest. Part of the reason experienced devs push back against TDD has to do with patterns and habits. It's safe to say that TDD feels awkward to anyone with other established work patterns. TDD is of course simply a methodology. It works well for some teams, and perhaps not for others. What it does do is impose a culture of testing and rigorousness, which is rarely a negative. Sure, you can decouple testing from TDD, but IME teams that apply TDD have more extensive coverage than those who don't. Causation correlation caveats apply. I personally dislike TDD because it disrupts the thought pattern I have become accustomed to using when developing software. I consider myself relatively junior, so I can only imagine how much of a workflow departure it must be for more senior engineers. However, just because it doesn't work optimally for me (or, optimally at first) doesn't invalidate the approach nor make anyone who uses it some brainwashed cult member.
- thomasmeeks 14y ago
  I think the issue is that TDD is handy for a lot of people. They (wrongly) assume it is equally as effective for everyone else. Then, they use it as a metric to judge others. It has become the "moral imperative" Bob Martin spoke of. Which is truly awful, and elicits a strong response from many who do not find TDD that useful. Quite a bit of job postings list TDD as a requirement, in fact, which is silly. It is a bit like requiring vim or emacs. A couple months ago, in fact, I tripped on a blog post that said (paraphrased): If you do not do TDD, then you should re-evaluate your career as a developer. This is bullshit. It angers me because I keep meeting very smart junior developers carrying around a load of guilt over TDD. I'm not sure what it is about TDD that make people forget that these things are all tools. You put it in your bag of tricks and pull it out when it makes sense. You don't beat each other to death over what tools they use.
  - doktrin 14y ago
    > Quite a bit of job postings list TDD as a requirement, in fact, which is silly. It is a bit like requiring vim or emacs. It wouldn't surprise me if those were pair-only or pair-frequently shops, at which point it makes sense to have a common workflow & toolset across the team. Given the amount of cultural overlap TDD & pairing have (particularly in Ruby-land), this seems at least plausible. > A couple months ago, in fact, I tripped on a blog post that said (paraphrased): If you do not do TDD, then you should re-evaluate your career as a developer. This is bullshit. Agreed. However, there's a lot of bullshit on the internet on just about every conceivable subject. Not having read the blog in question, I wouldn't put too much stock in this post representing the opinion of the majority. > I'm not sure what it is about TDD that make people forget that these things are all tools. You put it in your bag of tricks and pull it out when it makes sense. You don't beat each other to death over what tools they use. Disputes over tools has nothing to do with TDD and is certainly not unique to it. I would need a spreadsheet or small database to keep track of the varied topics I've seen developers evangelize and/or get into emotional near-venomous arguments over. It didn't start with TDD, and will certainly not end with it. The appropriate response across the board is typically empiricism, and grounding all discussions in the axiom that Data Wins Arguments.

doktrin 14y ago

This reaction is a bit visceral, and unnecessarily so. The "cult" and "dogma" accusations sound fairly outlandish, to be honest. Part of the reason experienced devs push back against TDD has to do with patterns and habits. It's safe to say that TDD feels awkward to anyone with other established work patterns. TDD is of course simply a methodology. It works well for some teams, and perhaps not for others. What it does do is impose a culture of testing and rigorousness, which is rarely a negative. Sure, you can decouple testing from TDD, but IME teams that apply TDD have more extensive coverage than those who don't. Causation correlation caveats apply. I personally dislike TDD because it disrupts the thought pattern I have become accustomed to using when developing software. I consider myself relatively junior, so I can only imagine how much of a workflow departure it must be for more senior engineers. However, just because it doesn't work optimally for me (or, optimally at first) doesn't invalidate the approach nor make anyone who uses it some brainwashed cult member.

thomasmeeks 14y ago
I think the issue is that TDD is handy for a lot of people. They (wrongly) assume it is equally as effective for everyone else. Then, they use it as a metric to judge others. It has become the "moral imperative" Bob Martin spoke of. Which is truly awful, and elicits a strong response from many who do not find TDD that useful. Quite a bit of job postings list TDD as a requirement, in fact, which is silly. It is a bit like requiring vim or emacs. A couple months ago, in fact, I tripped on a blog post that said (paraphrased): If you do not do TDD, then you should re-evaluate your career as a developer. This is bullshit. It angers me because I keep meeting very smart junior developers carrying around a load of guilt over TDD. I'm not sure what it is about TDD that make people forget that these things are all tools. You put it in your bag of tricks and pull it out when it makes sense. You don't beat each other to death over what tools they use.
- doktrin 14y ago
  > Quite a bit of job postings list TDD as a requirement, in fact, which is silly. It is a bit like requiring vim or emacs. It wouldn't surprise me if those were pair-only or pair-frequently shops, at which point it makes sense to have a common workflow & toolset across the team. Given the amount of cultural overlap TDD & pairing have (particularly in Ruby-land), this seems at least plausible. > A couple months ago, in fact, I tripped on a blog post that said (paraphrased): If you do not do TDD, then you should re-evaluate your career as a developer. This is bullshit. Agreed. However, there's a lot of bullshit on the internet on just about every conceivable subject. Not having read the blog in question, I wouldn't put too much stock in this post representing the opinion of the majority. > I'm not sure what it is about TDD that make people forget that these things are all tools. You put it in your bag of tricks and pull it out when it makes sense. You don't beat each other to death over what tools they use. Disputes over tools has nothing to do with TDD and is certainly not unique to it. I would need a spreadsheet or small database to keep track of the varied topics I've seen developers evangelize and/or get into emotional near-venomous arguments over. It didn't start with TDD, and will certainly not end with it. The appropriate response across the board is typically empiricism, and grounding all discussions in the axiom that Data Wins Arguments.