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.