4 ms·

The linked author claims that TDD is not a good approach to develop algorithms by linking to an article by Peter Norvig in which he writes tests to develop and

by preek 15y ago

The linked author claims that TDD is not a good approach to develop algorithms by linking to an article by Peter Norvig in which he writes tests to develop and further prove correctness of his algorithm. Maybe he didn't write the tests first, but none the less it proves the upmost importance of tests. Btw, Peter Norvig himself has good things to say on TDD[1]. So using him in an argument against TDD whilst he's using tests is kinda self defeating. 1. http://gigamonkeys.wordpress.com/2009/10/05/coders-unit-testing/ http://gigamonkeys.wordpress.com/2009/10/05/coders-unit-test...

plinkplonk 15y ago
"Maybe he didn't write the tests first" Then he isn't doing TDD at all is he? "Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test ..." [Wikipedia] Using tests after you write your code, to test functionalty how it needs to be improved has been a common practice from the earliest days of sw dev. In other words, "the importance of tests" has never been in dispute. TDD is not so universally accepted. Testing is beneficial, sure. But the claim that TDD ,sometimes evangelized as "not a testing method, it is a design method" (roll eyes), actually helps in "deeply understanding your problem domain" needs more validation. Due Disclosure: I wrote the original blog post(EDIT: the blog post comparing the two Sudoku attempts not the OP for this HN discussion) . I personally think TDD is overhyped consultantware snake oil, but that is just my personal opinion. If it works for you, more power to you.
- preek 15y ago
  Plenty validation can be found in whole communities - anything concerning Ruby for example lives and breathes test or behavior driven development. Btw, Peter Norvig himself has good things to say on TDD[1]. So using him in an argument against TDD whilst he's using tests is kinda self defeating. 1. http://gigamonkeys.wordpress.com/2009/10/05/coders-unit-testing/ http://gigamonkeys.wordpress.com/2009/10/05/coders-unit-test...
  - deleted 15y ago
    [deleted]
  - plinkplonk 15y ago
    If the existence of working software is validation for a methodology, then plenty of first class software has been and is being written every day without "TDD" of any kind. By your logic that should validate the idea that lack of TDD is helpful. All I am saying is that extraordinary claims require strong evidence. also you quote selectively . Norvig goes on to say "But you can test all you want and if you don’t know how to approach the problem, you’re not going to get a solution." Hardly the ringing endorsement of TDD that you imply. Besides the original article contrasted Norvig's algorithmic insight based approach to Jeffries's "write tests to try to improve understanding" approach( (at which he fails miserably btw). In the very article you link to Seibel goes on to say (emphasis mine) "But he (Jeffries) did choose to tackle this particular problem using TDD, a technique in which he is supposed to be the expert? Why did he have so little success? One thing I noticed, reading through Jeffries’s blog posts, was that he got fixated on the problem of how to represent a Sudoku board. He immediately started writing tests of the low-level details of a few functions for manipulating a data structure representing the 9×9 Sudoku board and a few functions for getting at the rows, columns, and boxes of the board. (“Boxes” are what Sudoku players call the 3×3 squares subsquares of the 9×9 board.) Then he basically wandered around for the rest of his five blog postings fiddling with the representation, making it more “object oriented” and then fixing up the tests to work with the new representation and so on until eventually, it seems, he just got bored and gave up, having made only one minor stab at the problem of actually solving puzzles. I suspect, having done a small amount of TDD myself, that this is actually a pattern that arises when a programmer tries to apply TDD to a problem they just don’t know how to solve. If I was a high-priced consultant/trainer like Jeffries, I’d probably give this pattern a pithy name like “Going in Circles Means You Don’t Know What You’re Doing”. Because he had no idea how to tackle the real problem, the only kinds of tests he could think of were either the very high-level “the program works” kind which were obviously too much of a leap or low-level tests of nitty-gritty code that is necessary but not at all sufficient for a working solver." Hmm that doesn't sound like an example of "tdd is a way to deeply understand a domain". Sounds more like "if you are clueless, TDD leads you in circles". That isn't to say that TDD may not help in specific instances. But hey, paper and pencil, or reading up on the domain, or building a non TDD prototype are likely be much better. So if you claim that TDD improves domain understanding in any substantial fashion you need stronger evidence or logical reasoning than a truncated selective quote from an article that claims the exact opposite. All that said, if TDD is your favorite method of sw dev, good for you. I just find claims about it being a tool to "deeply understand the domain" somewhat dubious. Any but the most trivial domains need more than "TDD" to understand (imo). YMMV. This thread is overlong and so I'll exit with a friendly "adieu", and leave the field to you.
- preek 15y ago
  You did write that blog post? Nice job, man! I skimmed over the rest of the blog and it's got some pretty nice articles on. I especially like the one concerning VIM and Python[1]. 1. http://blog.dispatched.ch/2009/05/24/vim-as-python-ide/ http://blog.dispatched.ch/2009/05/24/vim-as-python-ide/

by preek 15y ago

plinkplonk 15y ago

"Maybe he didn't write the tests first" Then he isn't doing TDD at all is he? "Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes a failing automated test case that defines a desired improvement or new function, then produces code to pass that test ..." [Wikipedia] Using tests after you write your code, to test functionalty how it needs to be improved has been a common practice from the earliest days of sw dev. In other words, "the importance of tests" has never been in dispute. TDD is not so universally accepted. Testing is beneficial, sure. But the claim that TDD ,sometimes evangelized as "not a testing method, it is a design method" (roll eyes), actually helps in "deeply understanding your problem domain" needs more validation. Due Disclosure: I wrote the original blog post(EDIT: the blog post comparing the two Sudoku attempts not the OP for this HN discussion) . I personally think TDD is overhyped consultantware snake oil, but that is just my personal opinion. If it works for you, more power to you.

preek 15y ago
Plenty validation can be found in whole communities - anything concerning Ruby for example lives and breathes test or behavior driven development. Btw, Peter Norvig himself has good things to say on TDD[1]. So using him in an argument against TDD whilst he's using tests is kinda self defeating. 1. http://gigamonkeys.wordpress.com/2009/10/05/coders-unit-testing/ http://gigamonkeys.wordpress.com/2009/10/05/coders-unit-test...
- deleted 15y ago
  [deleted]
- plinkplonk 15y ago
  If the existence of working software is validation for a methodology, then plenty of first class software has been and is being written every day without "TDD" of any kind. By your logic that should validate the idea that lack of TDD is helpful. All I am saying is that extraordinary claims require strong evidence. also you quote selectively . Norvig goes on to say "But you can test all you want and if you don’t know how to approach the problem, you’re not going to get a solution." Hardly the ringing endorsement of TDD that you imply. Besides the original article contrasted Norvig's algorithmic insight based approach to Jeffries's "write tests to try to improve understanding" approach( (at which he fails miserably btw). In the very article you link to Seibel goes on to say (emphasis mine) "But he (Jeffries) did choose to tackle this particular problem using TDD, a technique in which he is supposed to be the expert? Why did he have so little success? One thing I noticed, reading through Jeffries’s blog posts, was that he got fixated on the problem of how to represent a Sudoku board. He immediately started writing tests of the low-level details of a few functions for manipulating a data structure representing the 9×9 Sudoku board and a few functions for getting at the rows, columns, and boxes of the board. (“Boxes” are what Sudoku players call the 3×3 squares subsquares of the 9×9 board.) Then he basically wandered around for the rest of his five blog postings fiddling with the representation, making it more “object oriented” and then fixing up the tests to work with the new representation and so on until eventually, it seems, he just got bored and gave up, having made only one minor stab at the problem of actually solving puzzles. I suspect, having done a small amount of TDD myself, that this is actually a pattern that arises when a programmer tries to apply TDD to a problem they just don’t know how to solve. If I was a high-priced consultant/trainer like Jeffries, I’d probably give this pattern a pithy name like “Going in Circles Means You Don’t Know What You’re Doing”. Because he had no idea how to tackle the real problem, the only kinds of tests he could think of were either the very high-level “the program works” kind which were obviously too much of a leap or low-level tests of nitty-gritty code that is necessary but not at all sufficient for a working solver." Hmm that doesn't sound like an example of "tdd is a way to deeply understand a domain". Sounds more like "if you are clueless, TDD leads you in circles". That isn't to say that TDD may not help in specific instances. But hey, paper and pencil, or reading up on the domain, or building a non TDD prototype are likely be much better. So if you claim that TDD improves domain understanding in any substantial fashion you need stronger evidence or logical reasoning than a truncated selective quote from an article that claims the exact opposite. All that said, if TDD is your favorite method of sw dev, good for you. I just find claims about it being a tool to "deeply understand the domain" somewhat dubious. Any but the most trivial domains need more than "TDD" to understand (imo). YMMV. This thread is overlong and so I'll exit with a friendly "adieu", and leave the field to you.
preek 15y ago
You did write that blog post? Nice job, man! I skimmed over the rest of the blog and it's got some pretty nice articles on. I especially like the one concerning VIM and Python[1]. 1. http://blog.dispatched.ch/2009/05/24/vim-as-python-ide/ http://blog.dispatched.ch/2009/05/24/vim-as-python-ide/