As you develop more on a software product it gets bigger, it gets more features and those features interact with each other. We can argue about whether its line

As you develop more on a software product it gets bigger, it gets more features and those features interact with each other. We can argue about whether its linear growth, sub linear or more but its going to keep increasing. Every 2 weeks say you get a new release which has all the features of the previous releases + 2 weeks more. Given a constant supply of QA testers how do you manually test an ever increasingly larger featureset? You don't you skip the regression testing. Almost all software studios without TDD working with short cycles do risk based testing, they test the new stuff and the things it might break. They don't test the major features if they don't think they were touched. So either you aren't refactoring and hence your code is rotting or you are and that risk based testing is missing areas that did have changes in practice. TDD changes that, it turns the ever increasing QA cost of regression and new tests into development of tests and the growth is in machine running time for the tests. It flattens the human effort meaning your software is better tested over time and all the old features are tested every release reducing the chances of regressions. If you don't release fast (12 months between releases) then its less of an issue because there is usually time to have a manual test team go at it and potentially delay release with bugs and regressions and such. But its one of the "G Forces", in order to develop at ever shorter cycles and be more agile to change you need to convert the human effort of testing into machine time and the only way we know of ensuring that happens is TDD.