5 ms·

I use TDD on all my projects. I also regard myself as extremely pragmatic in my work. If I felt I would do better without designing test-first I would not be do

by lyudmil 17y ago

I use TDD on all my projects. I also regard myself as extremely pragmatic in my work. If I felt I would do better without designing test-first I would not be doing it (on some projects I have less-than-full coverage because it felt like the investment was not worth it). On to my point... One thing that always frustrates me in these debates is all the hypothesizing people who are skeptical of TDD do about what it would mean if they were to use it. For example: "For the type of programming I'm learning/doing now (web programming in ruby on rails), the tests are never sufficient to test anything." RoR is specifically built to make test-driven web development easy. I'm not saying the poster is wrong not to use TDD on their project, just that statements like that should not be taken at face value. It is clear that at least for some people doing certain types of work TDD is a big help. That's an indisputable fact. Therefore, the only reasonable positions one might hold are the following: 1) I agree with these people. TDD is great and I use it all the time. 2) I don't want to use TDD. It just does not match the way I think about my work. I choose not to use it, but I do not claim to know why using it is a bad idea. 3) I tried TDD and mastered it. Anyone well-versed in TDD would confirm that I can do it "the right way". I found the following problems in my test-driven code: ... For those reasons I would recommend that people stay away. I think any other position would be disingenuous or lazy. Also note that only opinion 3 is in any way interesting to read about. It kind of feels like unless you're making that claim there is no useful way to comment on the utility of TDD.

DanielBMarkham 17y ago
I find your logic interesting. So let's say I have this new way of doing things. It's called "hit your head with a hammer". I'm crazy about it and wrote a bunch of books about it. Other people have tried hitting their head with a hammer and, although there are many detractors, there are also some big fans. So what you're saying is: we cannot make a legitimate (or "interesting") observation about "hit yourself in the head with a hammer" unless we also have mastered the art of doing it. Only then would we have something worthwhile to add. I'm not saying TDD is bad. What I'm saying is that it's perfectly fine to look at the phenomenon from the outside and make general observations about it. For instance, "TDD is very hard to impose on most teams" or "When implementing TDD for the first time, teams experience a significant drop in performance" I'm sure there are lots of others. Uncle Bob (and others) have made a mockery out of informed discussion in regards to TDD. Here's hoping we can keep a reasoned and civilized discussion going in the community.
- lyudmil 17y ago
  I agree. I would say the observations you give as examples are backed by evidence and thus interesting to read (and, in fact, legitimate). I stated my case badly, but I would include such statements in the third category. I meant what I said to be a call for civilized discussion about the topic which echoes your sentiment. I also wanted to point out that such discussions have an annoyingly low signal-to-noise ratio. [Edit] I also was not trying to suggest a general strategy for evaluating programming practices. I made the assertion it was clear TDD has value at least in certain contexts. In the case of TDD I think it is evident its benefits are subtle enough to approach the issue more carefully.
timwiseman 17y ago
While I have tried it, my experience with TDD is quite limited. With that said, you seem to be missing an option: 4. I have evaluated TDD, and I see its value in many cases. But I also see cases where it is not appropriate or at least suboptimal. I therefore consider on a project by project basis whether I should use it. My experience in TDD is nowhere near enough to be comfortable making statement 4 myself, but I have heard it made and I think even most people that disagree with it would see it as a reasonable position to hold.

by lyudmil 17y ago

DanielBMarkham 17y ago

I find your logic interesting. So let's say I have this new way of doing things. It's called "hit your head with a hammer". I'm crazy about it and wrote a bunch of books about it. Other people have tried hitting their head with a hammer and, although there are many detractors, there are also some big fans. So what you're saying is: we cannot make a legitimate (or "interesting") observation about "hit yourself in the head with a hammer" unless we also have mastered the art of doing it. Only then would we have something worthwhile to add. I'm not saying TDD is bad. What I'm saying is that it's perfectly fine to look at the phenomenon from the outside and make general observations about it. For instance, "TDD is very hard to impose on most teams" or "When implementing TDD for the first time, teams experience a significant drop in performance" I'm sure there are lots of others. Uncle Bob (and others) have made a mockery out of informed discussion in regards to TDD. Here's hoping we can keep a reasoned and civilized discussion going in the community.

lyudmil 17y ago
I agree. I would say the observations you give as examples are backed by evidence and thus interesting to read (and, in fact, legitimate). I stated my case badly, but I would include such statements in the third category. I meant what I said to be a call for civilized discussion about the topic which echoes your sentiment. I also wanted to point out that such discussions have an annoyingly low signal-to-noise ratio. [Edit] I also was not trying to suggest a general strategy for evaluating programming practices. I made the assertion it was clear TDD has value at least in certain contexts. In the case of TDD I think it is evident its benefits are subtle enough to approach the issue more carefully.

timwiseman 17y ago

While I have tried it, my experience with TDD is quite limited. With that said, you seem to be missing an option: 4. I have evaluated TDD, and I see its value in many cases. But I also see cases where it is not appropriate or at least suboptimal. I therefore consider on a project by project basis whether I should use it. My experience in TDD is nowhere near enough to be comfortable making statement 4 myself, but I have heard it made and I think even most people that disagree with it would see it as a reasonable position to hold.