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.

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!

True, but again, most problems I've been given are solved problems I just need to glue the parts together.

I do not design a sorting algorithm from scratch (without consulting any of the literature on writing sort) - I could but the result would probably be a variation of bubble sort. However I stand on the shoulders of giants. That means I already know bucket sort, quick sort, insertion sort, bogo sort (and several more that were covered in CS203). I have never encountered a situation in the real world where calling whatever sort is built into my language is not good enough.

Most problems are variations of take some data, do a little math, and [save for latter use, present to the user, or change some physical control]

In a similar vein, I've found it super-helpful when refactoring. It gives you extra confidence that your refactoring isn't gradually breaking important stuff.

You can't do TDD when "bug-fixing maintenance". It's a contradiction in terms.

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"?

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.

If you are that strict on your definition, yes you cannot TDD when fixing a bug. However all TDD advocates will tell you to write the test for the bug before fixing it. If the code was designed with TDD you will not have to refactor the code to write the test (though the test might be much bigger than it would need to be if the code was designed different). You seem to be describing working with legacy code though, not which is a different situation from TDD.

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.

Uncle Bob always has some clever things to say on TDD too: http://blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms-Ar...

and: http://blog.cleancoder.com/uncle-bob/2016/11/10/TDD-Doesnt-w...

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.

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.

Thank you for saying this loud.

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.)

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.

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).

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.

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.

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 ;)

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.