3 ms·

>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 an

by 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.
- thomasmeeks 14y ago
  Well, yes, if you take it to the ship first vs what amounts to waterfall extreme, there will be profound differences in the code. I suppose if you make it your mission to analyze code to determine whether or not your programmers are using TDD, you could figure it out. But then we're getting into a pretty artificial situation. Who cares if the code is clean and the project is successful? TDD may be a useful way to get to clean code for /some/, perhaps /most/. But this is not true of /all/. I'm not arguing against its usefulness for someone like you. That's silly, you obviously value it. I'm arguing against the "moral imperative," which is utter nonsense. TDD is neither necessary nor sufficient for success, and we should stop pretending that it is. I create a class, it has an interface with a purpose, and I test that interface. I don't write tests first, and I don't have trouble writing tests after I write the code. I organize my thoughts on pen and paper, and use very light documentation to test the size and purpose of my methods. The projects I work on are successful, everyone's happy. This is true of several other programmers I work with on a daily basis, but not all. Several also practice TDD, and it works for them.
  - jdlshore 14y ago
    You're moving the goalposts. I didn't say anything (and I'm pretty sure I never have said) about TDD being a moral imperative. Nor did I say it was necessary for success, nor sufficient. I said "It's reasonable for a job to require TDD... because the TDD workflow results in a qualitatively different code base." I chose an artificial example of how workflows change code to make the point obvious, but the real-world effect of TDD is night-and-day obvious in my experience. I value that difference to the point where TDD skill is a core part of my hiring decisions. I'm okay with you making different choices.
    - thomasmeeks 14y ago
      Well, sure, I'm not sure I really care about what particular employers require of their employees. I think it is silly, but I doubt you care much about what I think, either. It was a minor point to me (not to you), which is why we've diverged I think. My moral imperative comment is toward the overall topic, not you.

by doktrin 14y ago

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.

thomasmeeks 14y ago
Well, yes, if you take it to the ship first vs what amounts to waterfall extreme, there will be profound differences in the code. I suppose if you make it your mission to analyze code to determine whether or not your programmers are using TDD, you could figure it out. But then we're getting into a pretty artificial situation. Who cares if the code is clean and the project is successful? TDD may be a useful way to get to clean code for /some/, perhaps /most/. But this is not true of /all/. I'm not arguing against its usefulness for someone like you. That's silly, you obviously value it. I'm arguing against the "moral imperative," which is utter nonsense. TDD is neither necessary nor sufficient for success, and we should stop pretending that it is. I create a class, it has an interface with a purpose, and I test that interface. I don't write tests first, and I don't have trouble writing tests after I write the code. I organize my thoughts on pen and paper, and use very light documentation to test the size and purpose of my methods. The projects I work on are successful, everyone's happy. This is true of several other programmers I work with on a daily basis, but not all. Several also practice TDD, and it works for them.
- jdlshore 14y ago
  You're moving the goalposts. I didn't say anything (and I'm pretty sure I never have said) about TDD being a moral imperative. Nor did I say it was necessary for success, nor sufficient. I said "It's reasonable for a job to require TDD... because the TDD workflow results in a qualitatively different code base." I chose an artificial example of how workflows change code to make the point obvious, but the real-world effect of TDD is night-and-day obvious in my experience. I value that difference to the point where TDD skill is a core part of my hiring decisions. I'm okay with you making different choices.
  - thomasmeeks 14y ago
    Well, sure, I'm not sure I really care about what particular employers require of their employees. I think it is silly, but I doubt you care much about what I think, either. It was a minor point to me (not to you), which is why we've diverged I think. My moral imperative comment is toward the overall topic, not you.