5 ms·

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

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.
jdlshore 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." Sorry, no, TDD isn't like vim or emacs. Your choice of vim or emacs doesn't change the code you produce. TDD does. Whether you agree with TDD or not, it's completely reasonable for a job to require it, just as it's reasonable for a job to require that you know and use MVC (in their app), or Rails, or any other technical solution to a problem. If I'm hiring somebody, they have to know TDD and apply it, or they won't work for me any more. Period. Just like they have to know what local variables are and use them. Right or wrong, it's a coding/design standard, and it's perfectly reasonable for teams to choose and enforce their coding standards. Now, that person might be able to convince me that they have something that solves my problem (a need for easily-changed code that does what the programmer intended) better than TDD. Say, a fancy type system. If so, awesome! I'll listen. But "I'll use TDD when I feel like it" ain't gonna cut it.
- doktrin 14y ago
  >If I'm hiring somebody, they have to know TDD and apply it, or they won't work for me any more. Period. Just like they have to know what local variables are and use them. Right or wrong, it's a coding/design standard TDD is a workflow implementation and not a coding standard per se. This is to say, code written with or without TDD may be completely interchangeable. This is not true of a coding standard. Coding standards measurably and objectively affect the end product (i.e. "use local variables", "space/tab indentation", "no method greater than 500 lines", "follow an MVC pattern"). Can the same be said for TDD or [insert workflow implementation here]? This may be a nitpick, but I feel it's important since it highlights why there is such disagreement on this topic.
  - jdlshore 14y ago
    You and thomasmeeks both said this (that code written with or without TDD may be interchangeable) and I respectfully disagree. Sure, in theory, you could write the same code, but in practice it just doesn't happen. There's a significant difference in the kinds of code that are produced. Think of it this way. Imagine two different teams. One team has a workflow that involves carefully considering design possibilities and creating design models on paper, and only writing code after those design models have been iterated and refined for a good month. Another team dismisses that approach as waste, and instead prides themselves on their ability to ship. They start coding on the very first day. Although they care about design, their emphasis is on shipping code, and they would never waste time on modeling. These are workflow differences. Will the teams produce different code? Of course! They approach the work differently! That's what workflow differences mean. TDD is a different workflow that produces different code. That difference matters. (See also this reply elsewhere in this thread: http://news.ycombinator.com/item?id=5334366 http://news.ycombinator.com/item?id=5334366 ) Edit: I don't mean to say that TDD will lead to good code. Far from it. TDD done badly leads to some gawdawful messes. But TDD done well does lead to code that is qualitatively different than other workflows done well and that difference--the result of using TDD--is useful to me.

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.

jdlshore 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." Sorry, no, TDD isn't like vim or emacs. Your choice of vim or emacs doesn't change the code you produce. TDD does. Whether you agree with TDD or not, it's completely reasonable for a job to require it, just as it's reasonable for a job to require that you know and use MVC (in their app), or Rails, or any other technical solution to a problem. If I'm hiring somebody, they have to know TDD and apply it, or they won't work for me any more. Period. Just like they have to know what local variables are and use them. Right or wrong, it's a coding/design standard, and it's perfectly reasonable for teams to choose and enforce their coding standards. Now, that person might be able to convince me that they have something that solves my problem (a need for easily-changed code that does what the programmer intended) better than TDD. Say, a fancy type system. If so, awesome! I'll listen. But "I'll use TDD when I feel like it" ain't gonna cut it.

doktrin 14y ago
>If I'm hiring somebody, they have to know TDD and apply it, or they won't work for me any more. Period. Just like they have to know what local variables are and use them. Right or wrong, it's a coding/design standard TDD is a workflow implementation and not a coding standard per se. This is to say, code written with or without TDD may be completely interchangeable. This is not true of a coding standard. Coding standards measurably and objectively affect the end product (i.e. "use local variables", "space/tab indentation", "no method greater than 500 lines", "follow an MVC pattern"). Can the same be said for TDD or [insert workflow implementation here]? This may be a nitpick, but I feel it's important since it highlights why there is such disagreement on this topic.
- jdlshore 14y ago
  You and thomasmeeks both said this (that code written with or without TDD may be interchangeable) and I respectfully disagree. Sure, in theory, you could write the same code, but in practice it just doesn't happen. There's a significant difference in the kinds of code that are produced. Think of it this way. Imagine two different teams. One team has a workflow that involves carefully considering design possibilities and creating design models on paper, and only writing code after those design models have been iterated and refined for a good month. Another team dismisses that approach as waste, and instead prides themselves on their ability to ship. They start coding on the very first day. Although they care about design, their emphasis is on shipping code, and they would never waste time on modeling. These are workflow differences. Will the teams produce different code? Of course! They approach the work differently! That's what workflow differences mean. TDD is a different workflow that produces different code. That difference matters. (See also this reply elsewhere in this thread: http://news.ycombinator.com/item?id=5334366 http://news.ycombinator.com/item?id=5334366 ) Edit: I don't mean to say that TDD will lead to good code. Far from it. TDD done badly leads to some gawdawful messes. But TDD done well does lead to code that is qualitatively different than other workflows done well and that difference--the result of using TDD--is useful to me.