5 ms·

TDD is a feedback tool, not a religion

25 points by th3james 12y ago

trhway 12y ago
it doesn't matter what a something really is when its zealots come.
dominotw 12y ago
Martin Fowler is still relevant?
cuillevel3 12y ago
Nice blog post. The internet is an echo chamber. I'm happy DHHs keynote brought some sense back into the discussion. Fowlers and Becks comments are great, too.
claudiusd 12y ago
TDD forces you to describe what your code is supposed to do rather than how it works (which is common when testing after the fact). When your tests describe what your code is supposed to do, they will forever guarantee that your program does not lose any functionality or end-user value. Even after doing significant refactoring, you can be confident that your code still satisfies all of the requirements you've forgotten about. While your TDD methodology may be flawed, this focus on end-user value has proved itself time and time again. Discussions like this one only play into DHH's flawed logic and do the programming public a disservice by pretending like there's some argument about whether TDD is effective or not. TDD works great if you do it right. A TDD methodology may or may not work depending on the circumstance. Choose the methodology that's most appropriate for the situation and you will have success.
- Codhisattva 12y ago
  That's the best point made yet - use TDD only if it's appropriate.
  - Klinky 12y ago
    When it's appropriate is not always clear. Those drinking the Kool-Aid will probably say you should always use it. Probably the biggest sticking point for me is not knowing how your program should be structured ahead of time. You'll have trial and error along with plenty of refactoring, as you grapple with how the solution best fits the infrastructure you are writing for. Adding the overhead of writing tests for code/apis that are likely to change sounds like wasted effort. The fragmentation between different testing frameworks also doesn't help, with each having their own learning curve. Maybe people should focus on coding a minimum viable product, then revisit it after they understand better how their product should work in the infrastructure they are using. They will then have a better understanding of the tests they should write. The tests would likely come in handy as their program matures, and errors/downtime to their users becomes a bigger issue than pushing a product out the door.
  - wpietri 12y ago
    I think there are a lot of things whose appropriateness is hard to know unless you have some experience with it. That's especially true where you're trading short-term costs for long-term wins. For example, think of restaurant hygiene. Safe food handling is hard work. And if you skimp on it, it's easy to say, "Hey, doing X isn't really necessary; nothing bad happened." For me, TDD is similar, in that the benefits mainly come later, when you have a sizable code base that you can make big changes to without fear. I agree people should use it when appropriate; there are definitely times when I don't bother. But I'm concerned that people who haven't experienced success (and failure) with TDD will have poor intuition for when it's appropriate.
    - greenyoda 12y ago
      "For me, TDD is similar, in that the benefits mainly come later, when you have a sizable code base that you can make big changes to without fear." The ability to refactor without fear comes from having adequate test coverage. Whether you write the tests before you write the code (TDD) or after the code is completed doesn't seem to affect your ability to refactor at a later date.
Codhisattva 12y ago
DHH's use of hyperbolic metaphors discredits the point he's trying to make. He has no factual argument so he exaggerates small points and maligns practitioners. It's sad.
mkal_tsr 12y ago
* TDD is not the end-all-be-all * BDD is not the end-all-be-all * Waterfall/XP/Scrum/Kanban/next-year's-methodolgy-buzzword is not the end-all-be-all * An individual language or framework is not the end-all-be-all. I don't know what happened, but lately it seems like every freaking blog post related to technology or start-ups debates that X (not Y) is the holy-grail of Z-topic. There is no holy-grail, only context. Use your expanding knowledge and tool-set along with the context of the situation/task and form an appropriate solution.
- truncate 12y ago
  One of the few things I remember and find useful from Software Engineering class is that there is No Silver Bullet. :)
- jacques_chester 12y ago
  Would you say that there's no "Silver Bullet"?
  - mkal_tsr 12y ago
    If we admit there is no Silver Bullet, how will we ever generate link-baity headlines about programming methodologies to attempt to validate my beliefs as correct instead of being open-minded about different approaches? ;-)
deckiedan 12y ago
Not sure if I trust this argument, before we can really discuss it: 1) Write test to prove TDD exists 2) Write test to prove TDD is a tool 3) Write test to prove TDD gives feedback given good input 4) Write test to prove TDD gives feedback given bad input 5) Write test to prove TDD gives feedback given no input 6) Write test to prove TDD gives feedback given mulitple input(s) 7) Write tests to define how a religion should respond to certain criteria. 8) Write test to prove TDD when try to be used as a religion fails. 9) Mock TDD, in a friendly kind of way. :-) Yes, there are good points and bad points to TDD. I'm glad the concepts, debates, and frameworks exist. Even if I don't follow them 100%, they do help me to think about a lot of that stuff in projects I design. In everything, moderation. Currently I prefer thinking, tinkering, REPL/playing design until I have a basic structure working, and I can see how I want it all to work, and then write tests afterwards, fixing any bugs that the tests reveal. Experiment-Driven-Design, Test-Driven-Maintenance. This probably only works for small projects, though.
gaelow 12y ago
Can't disagree, but computer science is in serious need of less but better and well known, highly reliable software development standards. Something universal that makes us confident enough to say: If you follow this process you'll ALWAYS get the work done in the predicted time frame, and this will not happen: http://ykyuen.files.wordpress.com/2010/02/howprojectreallyworks1.jpg http://ykyuen.files.wordpress.com/2010/02/howprojectreallywo... One of my software engineering professors used to comment often that if architects and structural engineers didn't had those procedures, 9 out of 10 bridges would collapse and there would be no way to guarantee the remaining 10% would be fit to handle x amount of traffic on any given day. Software engineering is a new science, not thousands of years old like bridge building, so we are taken our first baby steps towards that kind of efficiency and reliability. TDD is one of them.

25 points by th3james 12y ago

trhway 12y ago

it doesn't matter what a something really is when its zealots come.

dominotw 12y ago

Martin Fowler is still relevant?

cuillevel3 12y ago

Nice blog post. The internet is an echo chamber. I'm happy DHHs keynote brought some sense back into the discussion. Fowlers and Becks comments are great, too.

claudiusd 12y ago

TDD forces you to describe what your code is supposed to do rather than how it works (which is common when testing after the fact). When your tests describe what your code is supposed to do, they will forever guarantee that your program does not lose any functionality or end-user value. Even after doing significant refactoring, you can be confident that your code still satisfies all of the requirements you've forgotten about. While your TDD methodology may be flawed, this focus on end-user value has proved itself time and time again. Discussions like this one only play into DHH's flawed logic and do the programming public a disservice by pretending like there's some argument about whether TDD is effective or not. TDD works great if you do it right. A TDD methodology may or may not work depending on the circumstance. Choose the methodology that's most appropriate for the situation and you will have success.

Codhisattva 12y ago
That's the best point made yet - use TDD only if it's appropriate.
- Klinky 12y ago
  When it's appropriate is not always clear. Those drinking the Kool-Aid will probably say you should always use it. Probably the biggest sticking point for me is not knowing how your program should be structured ahead of time. You'll have trial and error along with plenty of refactoring, as you grapple with how the solution best fits the infrastructure you are writing for. Adding the overhead of writing tests for code/apis that are likely to change sounds like wasted effort. The fragmentation between different testing frameworks also doesn't help, with each having their own learning curve. Maybe people should focus on coding a minimum viable product, then revisit it after they understand better how their product should work in the infrastructure they are using. They will then have a better understanding of the tests they should write. The tests would likely come in handy as their program matures, and errors/downtime to their users becomes a bigger issue than pushing a product out the door.
- wpietri 12y ago
  I think there are a lot of things whose appropriateness is hard to know unless you have some experience with it. That's especially true where you're trading short-term costs for long-term wins. For example, think of restaurant hygiene. Safe food handling is hard work. And if you skimp on it, it's easy to say, "Hey, doing X isn't really necessary; nothing bad happened." For me, TDD is similar, in that the benefits mainly come later, when you have a sizable code base that you can make big changes to without fear. I agree people should use it when appropriate; there are definitely times when I don't bother. But I'm concerned that people who haven't experienced success (and failure) with TDD will have poor intuition for when it's appropriate.
  - greenyoda 12y ago
    "For me, TDD is similar, in that the benefits mainly come later, when you have a sizable code base that you can make big changes to without fear." The ability to refactor without fear comes from having adequate test coverage. Whether you write the tests before you write the code (TDD) or after the code is completed doesn't seem to affect your ability to refactor at a later date.

Codhisattva 12y ago

DHH's use of hyperbolic metaphors discredits the point he's trying to make. He has no factual argument so he exaggerates small points and maligns practitioners. It's sad.

mkal_tsr 12y ago

* TDD is not the end-all-be-all * BDD is not the end-all-be-all * Waterfall/XP/Scrum/Kanban/next-year's-methodolgy-buzzword is not the end-all-be-all * An individual language or framework is not the end-all-be-all. I don't know what happened, but lately it seems like every freaking blog post related to technology or start-ups debates that X (not Y) is the holy-grail of Z-topic. There is no holy-grail, only context. Use your expanding knowledge and tool-set along with the context of the situation/task and form an appropriate solution.

truncate 12y ago
One of the few things I remember and find useful from Software Engineering class is that there is No Silver Bullet. :)
jacques_chester 12y ago
Would you say that there's no "Silver Bullet"?
- mkal_tsr 12y ago
  If we admit there is no Silver Bullet, how will we ever generate link-baity headlines about programming methodologies to attempt to validate my beliefs as correct instead of being open-minded about different approaches? ;-)

deckiedan 12y ago

Not sure if I trust this argument, before we can really discuss it: 1) Write test to prove TDD exists 2) Write test to prove TDD is a tool 3) Write test to prove TDD gives feedback given good input 4) Write test to prove TDD gives feedback given bad input 5) Write test to prove TDD gives feedback given no input 6) Write test to prove TDD gives feedback given mulitple input(s) 7) Write tests to define how a religion should respond to certain criteria. 8) Write test to prove TDD when try to be used as a religion fails. 9) Mock TDD, in a friendly kind of way. :-) Yes, there are good points and bad points to TDD. I'm glad the concepts, debates, and frameworks exist. Even if I don't follow them 100%, they do help me to think about a lot of that stuff in projects I design. In everything, moderation. Currently I prefer thinking, tinkering, REPL/playing design until I have a basic structure working, and I can see how I want it all to work, and then write tests afterwards, fixing any bugs that the tests reveal. Experiment-Driven-Design, Test-Driven-Maintenance. This probably only works for small projects, though.

gaelow 12y ago

Can't disagree, but computer science is in serious need of less but better and well known, highly reliable software development standards. Something universal that makes us confident enough to say: If you follow this process you'll ALWAYS get the work done in the predicted time frame, and this will not happen: http://ykyuen.files.wordpress.com/2010/02/howprojectreallyworks1.jpg http://ykyuen.files.wordpress.com/2010/02/howprojectreallywo... One of my software engineering professors used to comment often that if architects and structural engineers didn't had those procedures, 9 out of 10 bridges would collapse and there would be no way to guarantee the remaining 10% would be fit to handle x amount of traffic on any given day. Software engineering is a new science, not thousands of years old like bridge building, so we are taken our first baby steps towards that kind of efficiency and reliability. TDD is one of them.