4 ms·

I'm a raving TDD/BDD fanatic, and this kata still makes me cringe a little. At least they finally converge on a plausible-looking solution. Sadly, some TDD kata

by ekidd 16y ago

I'm a raving TDD/BDD fanatic, and this kata still makes me cringe a little. At least they finally converge on a plausible-looking solution. Sadly, some TDD katas on the web turn into train wrecks. See Ron Jeffries' Sudoku solver, for example: http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.com/2007/04/learning-from-sudoku-s... If I were implementing this algorithm using TDD, I'd first write down a bunch of test cases, and then try the obvious algorithm. If that worked, I'd test a few more corner cases. There's really no reason why you have to blindly stagger through the design space when the algorithm is obvious.

nostrademons 16y ago
I think this is a problem with a lot of methodologies, in that they often obscure that the point is to write good software. If you can write good software without following the methodology, do that. All these techniques - agile, scrum, stand-up meetings, CRC cards, TDD, pair programming, code review, unit tests - are just tools at your disposal to make writing the program go smoother. Google's methodology for writing quality software is basically: 1. Hire good people. 2. Let them do what they need to to get the product out the door. This seems to have been adopted by FaceBook as well. I wish more companies would consider it instead of adopting the snake oil that a bunch of consultancies peddle.
- hello_moto 16y ago
  Google does a lot of test automation. I don't know if they do test-first or not but I heard that new-hire is given the "Working Effectively with Legacy Code", written by someone who works with Uncle Bob. At Google, there is a special role called Software Engineer in Test: they write tools to help developers debug performance issue, they also sit down with developers to help them to make their code more testable (this happened when you don't do test-first, sometime/once-in-a-while, developers will write code that's not easily testable via automation tests). Google is huge fans of code-review (probably that's why Andy Hertzfeld dislike Google). In contrast, Facebook probably doesn't do these practices (or did them in minimum). Facebook subscribes themselves to cowboy culture. Few days ago there were 2 posts in HN complaining about the Facebook API quality and documentation. I've used Facebook since 2006 and I do notice that their software is buggy whenever they push a newer build (you can tell: as soon as things degenerate, they just pushed the latest build). Aditya, who was the Director of Engineer back in 2008 (don't know if he's still), gave a talk recorded by InfoQ. He was asked about the state of unit-tests (or automation tests) and he said that the number of tests are minimum and not as many as he would've liked it to be. I know that some companies enforce Code-Review, TDD and CI: kaChing, IMVU. There are others (I think Disqus and Quora do that too, but I'm not sure to what extend) as well but they might not say it out-loud around here. The point is this: It doesn't matter what it calls (unit-tests, integration-tests, acceptance-tests), as long as you have extensive automated-tests, you can iterate faster and safer in the long-run. You can also deploy faster because you're quite sure nothing breaks. The old QA process no longer applies when people would write code and throw it over the wall to the QA and hope everything goes well (check Uncle Bob article about how we do QA is wrong).
Cushman 16y ago
Yeah, I didn't mean to say that I was questioning TDD in general— rather that it was obvious that this dev's insistence on solving the smallest part of the problem first was blinding him to the fact that the problem as a whole is quite small. And wow— that Sudoku epic is terrifying.
xyzzyz 16y ago
> (...) and then try the obvious algorithm. If that worked (...) Personally, I would not bother to implement an algorithm if I was not sure it works correctly -- if it turns out to be wrong, I had wasted my time.
- nostrademons 16y ago
  Hrmm? How else are you going to solve a problem that you've never faced before? And yes, wasted time is basically a necessary feature of working on problems that don't have a textbook solution.
  - xyzzyz 16y ago
    I am going to think about a problem, and if I come up with a solution I am sure is correct, I shall implement it. If I do not, I will search the web for a solution. If I find one, I will make sure it is correct, and then implement it. If I do not, I am going to ask some friends of mine about it. If they do not know the solution, I will temporaily loose the constraints and implement a solution that is "good enough", then I will make the problem my next research problem. Implementing an algorithm we are not sure that works correctly is not only a waste of time -- it is actually harmful, for it is possible to ship an algorithm that only seem to work correctly. Test cases will not prove that a solution is correct.
    - xyzzyz 16y ago
      What did I get downvoted for? I am relatively new here and I do not know all the things that are frowned upon?
      - nostrademons 16y ago
        I suspect that in many people's experience, "a solution that I am sure is correct" is anything but, until you've actually tested it. And testing it often takes far less time than puzzling over it and pondering. And so claiming that you never implement anything until you're absolutely certain it's correct smacks of youthful naivete, of the type common to college students who've never implemented anything. In many of the more interesting fields, it's often not well-defined what it means for an algorithm to be "correct" anyway. What would a "correct" web search algorithm look like? How about a "correct" recommendation algorithm? A "correct" flight fare prediction algorithm? A "correct" stock trading algorithm? A "correct" Starcraft AI? There're "better" and "worse" algorithms for these, but there's no such thing as a "correct" one. For many problems that do have an obvious "correct" solution (eg. OCR, face recognition, fare optimization), getting there is a nearly intractable problem, and the interesting part is in figuring out how you can approximate it as well as possible with the resources you have available is the best you can do.
grok2 16y ago
Actually this post from that same blog (to me) correctly summarizes the Kata exercise: http://pindancing.blogspot.com/2009/09/sudoku-in-coders-at-work.html http://pindancing.blogspot.com/2009/09/sudoku-in-coders-at-w... Specifically Norvigs quote in the blog: "I see tests more as a way of correcting errors rather than as a way of design. This extreme approach of saying, Well, the first thing you do is write a test that says I get the right answer at the end, and then you run it and see that it fails, and then you say, What do I need next? that doesn’t seem like the right way to design something to me."

by ekidd 16y ago

nostrademons 16y ago

I think this is a problem with a lot of methodologies, in that they often obscure that the point is to write good software. If you can write good software without following the methodology, do that. All these techniques - agile, scrum, stand-up meetings, CRC cards, TDD, pair programming, code review, unit tests - are just tools at your disposal to make writing the program go smoother. Google's methodology for writing quality software is basically: 1. Hire good people. 2. Let them do what they need to to get the product out the door. This seems to have been adopted by FaceBook as well. I wish more companies would consider it instead of adopting the snake oil that a bunch of consultancies peddle.

hello_moto 16y ago
Google does a lot of test automation. I don't know if they do test-first or not but I heard that new-hire is given the "Working Effectively with Legacy Code", written by someone who works with Uncle Bob. At Google, there is a special role called Software Engineer in Test: they write tools to help developers debug performance issue, they also sit down with developers to help them to make their code more testable (this happened when you don't do test-first, sometime/once-in-a-while, developers will write code that's not easily testable via automation tests). Google is huge fans of code-review (probably that's why Andy Hertzfeld dislike Google). In contrast, Facebook probably doesn't do these practices (or did them in minimum). Facebook subscribes themselves to cowboy culture. Few days ago there were 2 posts in HN complaining about the Facebook API quality and documentation. I've used Facebook since 2006 and I do notice that their software is buggy whenever they push a newer build (you can tell: as soon as things degenerate, they just pushed the latest build). Aditya, who was the Director of Engineer back in 2008 (don't know if he's still), gave a talk recorded by InfoQ. He was asked about the state of unit-tests (or automation tests) and he said that the number of tests are minimum and not as many as he would've liked it to be. I know that some companies enforce Code-Review, TDD and CI: kaChing, IMVU. There are others (I think Disqus and Quora do that too, but I'm not sure to what extend) as well but they might not say it out-loud around here. The point is this: It doesn't matter what it calls (unit-tests, integration-tests, acceptance-tests), as long as you have extensive automated-tests, you can iterate faster and safer in the long-run. You can also deploy faster because you're quite sure nothing breaks. The old QA process no longer applies when people would write code and throw it over the wall to the QA and hope everything goes well (check Uncle Bob article about how we do QA is wrong).

Cushman 16y ago

Yeah, I didn't mean to say that I was questioning TDD in general— rather that it was obvious that this dev's insistence on solving the smallest part of the problem first was blinding him to the fact that the problem as a whole is quite small. And wow— that Sudoku epic is terrifying.

xyzzyz 16y ago

> (...) and then try the obvious algorithm. If that worked (...) Personally, I would not bother to implement an algorithm if I was not sure it works correctly -- if it turns out to be wrong, I had wasted my time.

nostrademons 16y ago
Hrmm? How else are you going to solve a problem that you've never faced before? And yes, wasted time is basically a necessary feature of working on problems that don't have a textbook solution.
- xyzzyz 16y ago
  I am going to think about a problem, and if I come up with a solution I am sure is correct, I shall implement it. If I do not, I will search the web for a solution. If I find one, I will make sure it is correct, and then implement it. If I do not, I am going to ask some friends of mine about it. If they do not know the solution, I will temporaily loose the constraints and implement a solution that is "good enough", then I will make the problem my next research problem. Implementing an algorithm we are not sure that works correctly is not only a waste of time -- it is actually harmful, for it is possible to ship an algorithm that only seem to work correctly. Test cases will not prove that a solution is correct.
  - xyzzyz 16y ago
    What did I get downvoted for? I am relatively new here and I do not know all the things that are frowned upon?
    - nostrademons 16y ago
      I suspect that in many people's experience, "a solution that I am sure is correct" is anything but, until you've actually tested it. And testing it often takes far less time than puzzling over it and pondering. And so claiming that you never implement anything until you're absolutely certain it's correct smacks of youthful naivete, of the type common to college students who've never implemented anything. In many of the more interesting fields, it's often not well-defined what it means for an algorithm to be "correct" anyway. What would a "correct" web search algorithm look like? How about a "correct" recommendation algorithm? A "correct" flight fare prediction algorithm? A "correct" stock trading algorithm? A "correct" Starcraft AI? There're "better" and "worse" algorithms for these, but there's no such thing as a "correct" one. For many problems that do have an obvious "correct" solution (eg. OCR, face recognition, fare optimization), getting there is a nearly intractable problem, and the interesting part is in figuring out how you can approximate it as well as possible with the resources you have available is the best you can do.

grok2 16y ago

Actually this post from that same blog (to me) correctly summarizes the Kata exercise: http://pindancing.blogspot.com/2009/09/sudoku-in-coders-at-work.html http://pindancing.blogspot.com/2009/09/sudoku-in-coders-at-w... Specifically Norvigs quote in the blog: "I see tests more as a way of correcting errors rather than as a way of design. This extreme approach of saying, Well, the first thing you do is write a test that says I get the right answer at the end, and then you run it and see that it fails, and then you say, What do I need next? that doesn’t seem like the right way to design something to me."