One of the benefits, perhaps the main benefit, of TDD that's not mentioned here is that TDD leads to different solutions than "test later". You could probably make an argument that it often leads to cleaner, "better" solutions. The idea is that since you are forced to always adopt the simplest approach to implement the functionality required for the next incremental test, it allows patterns in the code to emerge that you might not have anticipated had you taken a "big bang" approach to your design - leading to a cleaner solution. Can you do it without formal TDD? Sure. I'd bet that many programmers with decades of experience do a certain amount of that naturally. Tackle the easiest part first, don't worry about the stuff that's not part of that, then let the design evolve, refactor as necessary as you go. But the industry is full of programmers with just a few years of experience, and they don't do that. Instead, they write baroque nightmares of complexity and unused functionality that they quickly get lost and confused in. It's incredibly rare to see a newish programmer write something that's too simple and clean :). Generally, I'd be surprised if I couldn't take a junior programmer's code and strip about 30-60% of it out in a few hours of refactoring. Why? Because they make all kinds of assumptions about the solution before they even start, and get committed to a sub-optimal approach right at the beginning that they can't back out of later on. I think those kinds of programmers (who are the majority) could benefit greatly from TDD.