That's a great point. I've given approximately zero thought to this, but would you say TDD (or any other requirements-driven design process) would avoid that kind of oversimplification?

> would you say TDD (or any other requirements-driven design process) would avoid that kind of oversimplification?

I haven't thought too much about how such things relate, but my first thought is that TDD seems biased towards oversimplification, since we do 'the simplest thing which makes the tests pass'. If we're testing that Bob's user profile shows the name "Bob", then the simplest thing is to have all profiles hard-coded to say "Bob". To fix this, TDD tells us to add more tests which check different names. That's before we've even begun to consider the hairy details of how names are used in different cultures.

It's a reasonable approach, but it's not "solving" the oversimplification problem, it's just shifting it into the test suite. It's similar to the problem of over-fitting in machine learning models, where we may need millions of input/output examples to narrow-down the intended behaviour.

I think the aggressive refactoring advocated by TDD manages to bias it away from overcomplication.

TDD should give you the simplest solution conforming to your spec (your tests). So it's all the necessary complexity without any unnecessary complexity to fulfill your testsuite, and ease of refactoring in case you need to change something more fundamental about your code.

At some point you need to specify which edge cases you need.

> it's all the necessary complexity without any unnecessary complexity to fulfill your testsuite

As I said, it doesn't solve the problem of overcomplication/simplification, it just shifts the burden on to the test suite instead of the program.