Well, possibly, and the dark side moon might be made of green cheese.
"X is … because y might be" is poor rhethoric. "Is" is the indicative mood, "might be" is the conditional mood, so such an argument lets the conditional overwhelm the indicative. That's useful if you wish to mislead or confuse, less useful if you wish to clarify.
Please supply an argument that TDD sometimes/often is overengineering.
In my experience (such as it is) the tests are shaped by the best-understood parts of the business goals. I've seen some ugly overengineering in the past decades, but most of them happened when people went off and implemented parts of the system that were not yet well understood.
"X is … because y might be" is poor rhethoric. "Is" is the indicative mood, "might be" is the conditional mood, so such an argument lets the conditional overwhelm the indicative. That's useful if you wish to mislead or confuse, less useful if you wish to clarify.
Please supply an argument that TDD sometimes/often is overengineering.
In my experience (such as it is) the tests are shaped by the best-understood parts of the business goals. I've seen some ugly overengineering in the past decades, but most of them happened when people went off and implemented parts of the system that were not yet well understood.