3 ms·

"TDD doesn't create design. You do." Sorry, but this is akin the fallacious "guns don't kill people" argument. Well, of course not, but they certainly make it

"TDD doesn't create design. You do." Sorry, but this is akin the fallacious "guns don't kill people" argument. Well, of course not, but they certainly make it easier. So does TDD make good design easier, or harder? I'm afraid that, for me, the article didn't provide an answer, or even anything bu the most superficial insight into the issues. For example, coding is often about exploring a problem, and in these cases I think TDD is a hindrance. But whatever the overall argument, TDD certainly changes how things are designed, and what kinds of things are easy or difficult to achieve. Indeed, writing tests can sometimes be more challenging than the code itself. Now that would be something worth further discussion.

crdoconnor 13y ago
>So does TDD make good design easier, or harder? I'm afraid that, for me, the article didn't provide an answer, or even anything bu the most superficial insight into the issues. It gives a perfectly fine answer: design is as hard with TDD as without TDD. Doing TDD simply changes the type of design mistakes that you're likely to make. For what it's worth, he nailed the design antipatterns. I've come across every single one of the ones he mentioned.
- nawitus 12y ago
  A more interesting question is whether or not TDD leads to better design or not. Even if TDD doesn't change the difficult of good design, it can empirically affect the level of design. Here's a theoretical example of how that's possible: changing the design before tests are written and without using TDD requires less time than when using TDD. The reason (hypothetically) is simple: you need to rewrite tests more if you're using TDD. This might lead developers to redesign software slightly less on average if they're using TDD.
benihana 13y ago
>But whatever the overall argument, TDD certainly changes how things are designed I think you missed this point completely, and you made it hard to ever get it when you compared TDD to a highly contentious issue in guns - rather than this just being an issue of methodology in coding, it's now a political issue as well. Regardless, TDD doesn't change how things are designed. TDD is a methodology, a way of doing things. It's a tool - it can't change things without human input. TDD does not change design; it can't. It only amplifies a person's ability to do that by making poor abstractions and weak boundaries clear and that is the power of it as a methodology.
- the_af 12y ago
  First, let me say I agree with you. TDD is a methodology, a tool, and it's been found helpful by many practitioners. That said, the problem is that TDD is often presented as The One True Way. Even people who should know better say "I'm not saying TDD is the only way, but if you don't do it, show me what you use that is as good". (I'm looking at you, Uncle Bob). This has the unstated assumption that TDD is the best tool available, and that you're doing something wrong if you don't use it, and that you have the burden to explain why you do something else. Again, even people who claim "use the right tool for the right job" will usually look at you with skepticism if you claim you've found a job for which TDD is not good, somewhat negating their claim that they're open-minded about it. I've heard the following (somewhat contradictory) claims about TDD: - "Every single line you write must be covered by TDD, otherwise you're doing it wrong." - "TDD is about design, not about testing. Testing is merely a nice side-effect." - "You cannot refactor safely without TDD." - "If your test isn't red first, you're doing it wrong." - "TDD makes your code more testable." - "TDD can drive design and lead you to a solution." - "A reasonable way to develop a mathematical function like Fibonacci is to use TDD" (I never can get if the person writing this knows that's not the case but forgets to explain it, or if they truly believe that. Either way, they hurt the case for TDD). Each of these assumptions is either demonstrably wrong or at least arguable. But TDD zealots (again, not talking about commenters on HN, but TDD's well-known evangelists) will make you feel bad if you doubt a single one. IMO, this is the single thing driving most of the backlash against TDD. If we instead demote TDD from its priviledged place to "one methodology, not formally proven, that may or may not work for you", I presume the backlash will go away. And so will the people who tell you that if you're not doing TDD, you're doing development wrong.
  - SoftwareMaven 12y ago
    Software development has a long and infamous history of The One True Way to Write Code(tm). Object oriented, agile, dynamic typing, and TDD[1] have all had their moments where it was "known" that it is the only way to efficiently create quality, maintainable software. All of them have their place, but none have managed to maintain the level of importance their evangelists promoted. I've often wondered why software development is so prone to evangelical thinking. I think it is related to egos and the relative immaturity if the field. I've gotten to where I filter out the value from the hype. There are important lessons to learn from the hype, but my experience is people become more concerned about the religious practice than the actual software. 1. TDD is simply the latest. And, like the others, TDD will have a long-lasting impact on software development. Eventually, reasonable testing will be part of the collective software culture (it's getting closer, but not quite there), and tests will be written for most projects. At that point, the TDD evangelicals will have nothing but strawmen to fight against, and the next religion will form.

crdoconnor 13y ago

>So does TDD make good design easier, or harder? I'm afraid that, for me, the article didn't provide an answer, or even anything bu the most superficial insight into the issues. It gives a perfectly fine answer: design is as hard with TDD as without TDD. Doing TDD simply changes the type of design mistakes that you're likely to make. For what it's worth, he nailed the design antipatterns. I've come across every single one of the ones he mentioned.

nawitus 12y ago
A more interesting question is whether or not TDD leads to better design or not. Even if TDD doesn't change the difficult of good design, it can empirically affect the level of design. Here's a theoretical example of how that's possible: changing the design before tests are written and without using TDD requires less time than when using TDD. The reason (hypothetically) is simple: you need to rewrite tests more if you're using TDD. This might lead developers to redesign software slightly less on average if they're using TDD.

benihana 13y ago

>But whatever the overall argument, TDD certainly changes how things are designed I think you missed this point completely, and you made it hard to ever get it when you compared TDD to a highly contentious issue in guns - rather than this just being an issue of methodology in coding, it's now a political issue as well. Regardless, TDD doesn't change how things are designed. TDD is a methodology, a way of doing things. It's a tool - it can't change things without human input. TDD does not change design; it can't. It only amplifies a person's ability to do that by making poor abstractions and weak boundaries clear and that is the power of it as a methodology.

the_af 12y ago
First, let me say I agree with you. TDD is a methodology, a tool, and it's been found helpful by many practitioners. That said, the problem is that TDD is often presented as The One True Way. Even people who should know better say "I'm not saying TDD is the only way, but if you don't do it, show me what you use that is as good". (I'm looking at you, Uncle Bob). This has the unstated assumption that TDD is the best tool available, and that you're doing something wrong if you don't use it, and that you have the burden to explain why you do something else. Again, even people who claim "use the right tool for the right job" will usually look at you with skepticism if you claim you've found a job for which TDD is not good, somewhat negating their claim that they're open-minded about it. I've heard the following (somewhat contradictory) claims about TDD: - "Every single line you write must be covered by TDD, otherwise you're doing it wrong." - "TDD is about design, not about testing. Testing is merely a nice side-effect." - "You cannot refactor safely without TDD." - "If your test isn't red first, you're doing it wrong." - "TDD makes your code more testable." - "TDD can drive design and lead you to a solution." - "A reasonable way to develop a mathematical function like Fibonacci is to use TDD" (I never can get if the person writing this knows that's not the case but forgets to explain it, or if they truly believe that. Either way, they hurt the case for TDD). Each of these assumptions is either demonstrably wrong or at least arguable. But TDD zealots (again, not talking about commenters on HN, but TDD's well-known evangelists) will make you feel bad if you doubt a single one. IMO, this is the single thing driving most of the backlash against TDD. If we instead demote TDD from its priviledged place to "one methodology, not formally proven, that may or may not work for you", I presume the backlash will go away. And so will the people who tell you that if you're not doing TDD, you're doing development wrong.
- SoftwareMaven 12y ago
  Software development has a long and infamous history of The One True Way to Write Code(tm). Object oriented, agile, dynamic typing, and TDD[1] have all had their moments where it was "known" that it is the only way to efficiently create quality, maintainable software. All of them have their place, but none have managed to maintain the level of importance their evangelists promoted. I've often wondered why software development is so prone to evangelical thinking. I think it is related to egos and the relative immaturity if the field. I've gotten to where I filter out the value from the hype. There are important lessons to learn from the hype, but my experience is people become more concerned about the religious practice than the actual software. 1. TDD is simply the latest. And, like the others, TDD will have a long-lasting impact on software development. Eventually, reasonable testing will be part of the collective software culture (it's getting closer, but not quite there), and tests will be written for most projects. At that point, the TDD evangelicals will have nothing but strawmen to fight against, and the next religion will form.