5 ms·

No article about TDD, particularly one that shouts out to the respected Ron Jeffries http://ronjeffries.com/ http://ronjeffries.com/, is complete without mentio

No article about TDD, particularly one that shouts out to the respected Ron Jeffries http://ronjeffries.com/ http://ronjeffries.com/, is complete without mentioning the TDD Sudoku Fiasco :) Ravi has a nice summary: http://ravimohan.blogspot.se/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.se/2007/04/learning-from-sudoku-so... Peter Norvig's old-fashioned approach is excellent counterbalance: http://norvig.com/sudoku.html http://norvig.com/sudoku.html

Cephlin 9y ago
Uncle Bob always has some clever things to say on TDD too: http://blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms-Architecture.html http://blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms-Ar... and: http://blog.cleancoder.com/uncle-bob/2016/11/10/TDD-Doesnt-work.html http://blog.cleancoder.com/uncle-bob/2016/11/10/TDD-Doesnt-w...
- hota_mazi 9y ago
  I don't find most of the Uncle Bob writes to be clever, and especially when he writes about TDD. He's just too dogmatic to be credible to anyone working in the industry (and make no mistake, Uncle Bob knows absolutely nothing of the software industry in the 21st century). His writings are only here to promote himself, his books and his consultancy. That's it.
  - neuromantik8086 9y ago
    I weakly agree with this statement. While I think there is merit to TDD under some circumstances (that others have described quite elegantly and succinctly elsewhere in the this thread), my main takeaway from the Clean Coder was that if I ever got super burned out I should just start a consultancy. [addition]: I also find it weird how the Clean Coder seemed to encourage burnout by prescribing that you use your off-hours to hone your craft. While I agree that software engineering should be treated more like a craft (in particular, I'm thinking of the apprenticeship and craftsman ship culture that is prevalent in Germany / possibly other former Hansa areas), I don't think that it's reasonable to assume that people should sacrifice their personal time for it. I understand that sometimes this might be necessary (the proverbial night class to get up to speed with some new domain of knowledge), but his implying that surgeons constantly practice surgery during their off-hours (and really, short of illegally exhuming bodies, how would they do this?) seemed a bit of a naive and unrealistic ideal.
  - insulanian 9y ago
    Thank you for saying this loud.
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]
nikkettt 9y ago
Playing devil's advocate here: I'd say that algorithm design (Which is what a sudoku solver is) is a bad fit for TDD. However, I'd argue that most problems in commercial coding are of a more engineering/architectural type of nature. Here, outside-in TDD has it's place. Outside-in TDD can help you tackle problems that seem enormous, and slowly but steadily break them into smaller components.
- willvarfar 9y ago
  I find TDD useless as a way of poking at problems I don't actually know how to solve (as Jeffries found with Sudoku), in the way and slowing down when writing large new systems, and excellent when bug-fixing maintenance. Test Driven Debugging!
  - eropple 9y ago
    You can't do TDD when "bug-fixing maintenance". It's a contradiction in terms.
    - willvarfar 9y ago
      Curious. How so? Get a bug report. Write a unit test that reproduces the bug. Fix the bug. The unit test now passes. Check it in. Now its part of your growing regression suite. How is this not "test driven"?
      - eropple 9y ago
        Test-driven development refers specifically to building tests before implementations such that the impressions of the tests (which are communicating the external intent of whatever you're working on) are not colored by the particulars of an implementation. The tests you are writing are necessarily colored by the implementation you're fixing. This isn't bad (though I'd say it's less effective for most programming tasks than TDD), but it isn't TDD.
      - Jach 9y ago
        Where's the design? (To me TDD was always championed to help specifically with Design as much as the vague Development. When using the vague Development too loosely you run into a recursive problem because writing tests is itself development so do you use TDD for your tests?) Depending on how seriously you take the step of writing a unit test that reproduces the bug, you may be forced to refactor quite a lot of code to get that buggy section under test. Writing the test first can help guide your refactoring to avoid mocking the runtime world. But you're not designing anything, and it was all driven by the bug report.
ajross 9y ago
To be fair (and I'm no TDD fan personally), that mess wasn't really the fault of TDD at all. It was that Jeffries was learning how to write a Sudoku solver while he was writing his tests. If he started from Norvig's level of understanding, he surely could have written tests for an equivalently elegant solver quickly and simply. Learning how to solve a problem by iterative coding (and throwing away the intermediate solutions) is a time-honored tradition that works very well. TDD may be an imperfect vehicle for doing that, but it doesn't really change the calculus.
- willvarfar 9y ago
  The whole thing at the time was 'test driven design' - the idea that by writing tests, you could iterate your way to algorithms that solve problems you couldn't solve by critical up-front thinking. Test Driven Design fizzled and quietly died just after the Sudoku Fiasco ;)
krmboya 9y ago
Well, to me it seems that if you stretch the idea of separation of concerns, you should separate the process finding out what you should do, from the process of how you should do it right.
mjw1007 9y ago
The 'Fiasco' is a bit of an unfair comparison, because Jeffries is deliberately providing a 'stream of consciousness' writeup while Norvig's is a cleaned-up version with false starts removed. (You can tell Norvig's code worked differently at one point by looking at the return value of assign(), for example.)
- willvarfar 9y ago
  I would be staggered if Norvig's approach ever wasn't constraint propagation and backtracking. Solving Sudoku is blindingly obvious even to mere mortals with even a iota of exposure to computer science and algorithms.
  - mjw1007 9y ago
    Sure, Norvig knew how to solve the problem from the start. But that's another reason why the "TDD Sudoku Fiasco" blogpost isn't a terribly useful source of information (or, from another point of view, why it isn't a great way to persuade a TDD afficionado to change their mind).
plinkplonk 9y ago
that 3 line post is the most popular blog post I ever wrote. I got a lot of nasty mail from agile consultants, but it was worth it, heh! Which reminds me, I haven't blogged in years. One day I just stopped. Perhaps it is time to restart.
- mlvljr 9y ago
  you do that

Cephlin 9y ago

Uncle Bob always has some clever things to say on TDD too: http://blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms-Architecture.html http://blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms-Ar... and: http://blog.cleancoder.com/uncle-bob/2016/11/10/TDD-Doesnt-work.html http://blog.cleancoder.com/uncle-bob/2016/11/10/TDD-Doesnt-w...

hota_mazi 9y ago
I don't find most of the Uncle Bob writes to be clever, and especially when he writes about TDD. He's just too dogmatic to be credible to anyone working in the industry (and make no mistake, Uncle Bob knows absolutely nothing of the software industry in the 21st century). His writings are only here to promote himself, his books and his consultancy. That's it.
- neuromantik8086 9y ago
  I weakly agree with this statement. While I think there is merit to TDD under some circumstances (that others have described quite elegantly and succinctly elsewhere in the this thread), my main takeaway from the Clean Coder was that if I ever got super burned out I should just start a consultancy. [addition]: I also find it weird how the Clean Coder seemed to encourage burnout by prescribing that you use your off-hours to hone your craft. While I agree that software engineering should be treated more like a craft (in particular, I'm thinking of the apprenticeship and craftsman ship culture that is prevalent in Germany / possibly other former Hansa areas), I don't think that it's reasonable to assume that people should sacrifice their personal time for it. I understand that sometimes this might be necessary (the proverbial night class to get up to speed with some new domain of knowledge), but his implying that surgeons constantly practice surgery during their off-hours (and really, short of illegally exhuming bodies, how would they do this?) seemed a bit of a naive and unrealistic ideal.
- insulanian 9y ago
  Thank you for saying this loud.
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]

nikkettt 9y ago

Playing devil's advocate here: I'd say that algorithm design (Which is what a sudoku solver is) is a bad fit for TDD. However, I'd argue that most problems in commercial coding are of a more engineering/architectural type of nature. Here, outside-in TDD has it's place. Outside-in TDD can help you tackle problems that seem enormous, and slowly but steadily break them into smaller components.

willvarfar 9y ago
I find TDD useless as a way of poking at problems I don't actually know how to solve (as Jeffries found with Sudoku), in the way and slowing down when writing large new systems, and excellent when bug-fixing maintenance. Test Driven Debugging!
- eropple 9y ago
  You can't do TDD when "bug-fixing maintenance". It's a contradiction in terms.
  - willvarfar 9y ago
    Curious. How so? Get a bug report. Write a unit test that reproduces the bug. Fix the bug. The unit test now passes. Check it in. Now its part of your growing regression suite. How is this not "test driven"?
    - eropple 9y ago
      Test-driven development refers specifically to building tests before implementations such that the impressions of the tests (which are communicating the external intent of whatever you're working on) are not colored by the particulars of an implementation. The tests you are writing are necessarily colored by the implementation you're fixing. This isn't bad (though I'd say it's less effective for most programming tasks than TDD), but it isn't TDD.
    - Jach 9y ago
      Where's the design? (To me TDD was always championed to help specifically with Design as much as the vague Development. When using the vague Development too loosely you run into a recursive problem because writing tests is itself development so do you use TDD for your tests?) Depending on how seriously you take the step of writing a unit test that reproduces the bug, you may be forced to refactor quite a lot of code to get that buggy section under test. Writing the test first can help guide your refactoring to avoid mocking the runtime world. But you're not designing anything, and it was all driven by the bug report.

ajross 9y ago

To be fair (and I'm no TDD fan personally), that mess wasn't really the fault of TDD at all. It was that Jeffries was learning how to write a Sudoku solver while he was writing his tests. If he started from Norvig's level of understanding, he surely could have written tests for an equivalently elegant solver quickly and simply. Learning how to solve a problem by iterative coding (and throwing away the intermediate solutions) is a time-honored tradition that works very well. TDD may be an imperfect vehicle for doing that, but it doesn't really change the calculus.

willvarfar 9y ago
The whole thing at the time was 'test driven design' - the idea that by writing tests, you could iterate your way to algorithms that solve problems you couldn't solve by critical up-front thinking. Test Driven Design fizzled and quietly died just after the Sudoku Fiasco ;)

krmboya 9y ago

Well, to me it seems that if you stretch the idea of separation of concerns, you should separate the process finding out what you should do, from the process of how you should do it right.

mjw1007 9y ago

The 'Fiasco' is a bit of an unfair comparison, because Jeffries is deliberately providing a 'stream of consciousness' writeup while Norvig's is a cleaned-up version with false starts removed. (You can tell Norvig's code worked differently at one point by looking at the return value of assign(), for example.)

willvarfar 9y ago
I would be staggered if Norvig's approach ever wasn't constraint propagation and backtracking. Solving Sudoku is blindingly obvious even to mere mortals with even a iota of exposure to computer science and algorithms.
- mjw1007 9y ago
  Sure, Norvig knew how to solve the problem from the start. But that's another reason why the "TDD Sudoku Fiasco" blogpost isn't a terribly useful source of information (or, from another point of view, why it isn't a great way to persuade a TDD afficionado to change their mind).

plinkplonk 9y ago

that 3 line post is the most popular blog post I ever wrote. I got a lot of nasty mail from agile consultants, but it was worth it, heh! Which reminds me, I haven't blogged in years. One day I just stopped. Perhaps it is time to restart.

mlvljr 9y ago
you do that