You (and the author) make a very good point here, and I wasn't disputing that point directly. The issue I was disputing is a generalization made by the author a

You (and the author) make a very good point here, and I wasn't disputing that point directly. The issue I was disputing is a generalization made by the author and the people who are insisting on their own 'only way to create software' ideologies. Arguing about software as a whole is flawed, and discussions like this must always be put into context and evidence for or against must be very specific about the exact context. This ties into a similar issue in management academics in which, for decades, people tried to prove a 'best way to manage a company'. Management academics have now moved on from this and all management recommendations are always very rooted in as deep a specific as possible. Software best practices need to make the same transition now. Simply saying 'TDD is best' is the same as saying 'performance linked compensation is best'. Awhile back, a number of idealists very strongly touted the performance linked compensation angle in the same way that a number of software idealists are touting TDD. There is nothing wrong with either idea when used pragmatically and in the correct situations, but the important part for the future and for software as a whole is to discovery the situations in which TDD shines, and the situations it doesn't. Only by breaking it down as specific as possible can we get any real value from TDD recommendations. So, if you cannot prove that it's right or better, why do you say that it is? I think this is the point of the article. What I'm trying to get at is that if we can drill down to the specifics we may be able to actually prove things in very specific industries/team structures. We must move away from debating 'software development' as a whole before we can arrive at anything useful though.