5 ms·

>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

>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.
jacknews 12y ago
I think you are missing my point. That is, that the argument 'TDD doesn't do design, people do' is a glib and not very illuminating argument, just as when it is used in the context of guns. Of course design is ultimately up to people, but they do that design in an environment of tools and methodologies. Those tools affect the way people approach problems, and what kinds of things are easy vs difficult. So tools do matter, and choice of tools is also a political issue in that there is no absolute "right" or "wrong", just better or worse depending on when and how they are used.

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.

jacknews 12y ago

I think you are missing my point. That is, that the argument 'TDD doesn't do design, people do' is a glib and not very illuminating argument, just as when it is used in the context of guns. Of course design is ultimately up to people, but they do that design in an environment of tools and methodologies. Those tools affect the way people approach problems, and what kinds of things are easy vs difficult. So tools do matter, and choice of tools is also a political issue in that there is no absolute "right" or "wrong", just better or worse depending on when and how they are used.