I remember when those papers were hitting headlines. The opinion of anti-TDDs back then was : "yes, it's certainly a good thing for students learning how to code", following the idea that it forced them to consider architecture rather than jumping on adding lines of code, and that experienced developers don't need it as much (thus, the conclusion was that those studies were biased toward people learning to code).

The answer of pro-TDDs was that you always benefit it, even when already experienced. I agreed with them, back then.

I don't remember seeing those about IBM and Microsoft, though. What were their conclusions?

Nowadays, I do what I jokingly call "documentation driven development", as a follow up for "top down development" that cucumber and the likes introduced. I'll usually first write about the problem I'm solving, then generally write about how I solve it, then write about components needed to implement that solution, then what those components do in details, then I write function signatures, and I stop there. I give it a month going back to it from time to time and I always figure out problems with it.

Refactoring that is awesome : no tests to change, no application code to change, it's just manipulating pure architecture, and it's incredibly fast to change while still being able to keep everything in mind. Careful planning is kind of replacing for me what TDD used to do (for the part about designing proper architecture ; I do integration testing for the part about catching regressions).

But really, I feel today that the methodology doesn't matter much : agile or not, TDD or not, this or that, whatever. What matters the most is people. The same methodology will have opposite results depending on who is applying it. I guess some methodologies will be better than others for learning programming, but I have really no clue how to measure that :)