This is such an awesome summary, I'm just going to start here without actually reading the paper :-). I'll say up front that I'm a TDD/Unit test kind of guy.

This is such an awesome summary, I'm just going to start here without actually reading the paper :-). I'll say up front that I'm a TDD/Unit test kind of guy. I'm also not generally a fan of London School/Outside-In style (but will obviously use it when circumstances demand it). So I'm probably exactly the kind of person that should disagree with the above. But I don't really disagree that much. One thing I've noticed is that there really is more than one way to skin a cat. Some people like to have a more linear style in their code. I've found that such people tend to have good memories and considerable ability at reasoning. They can see a fairly large piece of code and see quickly where the errors are. They can remember that one piece of code on the other side of the project did something one way and code on this side of the project does it another way. These people will often look at my code and it looks disjointed to them. They can't read the code and get a sense of what it is doing. They find themselves jumping around through hundreds of files just to figure out what's going on. If I have any ability at all it's really much more in the spatial relations side. I can visualise networks easily and reason about them. I can never remember the details about how things are implemented and I'm a very slow reader (I'm dyslexic). I depend on trust. I want to be able to see a function and tell in 5 seconds whether or not it is correct. I then rely on tests to tell me when I have violated some assumptions somewhere -- because I don't bother to learn and have no capacity for remembering all the assumptions in the system. Unit tests and the intense factoring that occurs when doing TDD (at least in a non-mocking style) favours a style where you admit imperfect knowledge about the system. It then gives you a framework for reasoning about the system. People (even on my team) are often surprised that I haven't used a debugger for at least 10-15 years. Tests are really a misnomer -- they don't verify the correct execution of the code. What they do is probe the execution of the code. It tells me what the code is actually doing and documents my assumptions about what it should be doing. If there is an error, there will be a mismatch in the two. I may or may not have an explicit test that fails during that mismatch, but I should be able to reason about it effectively. It's a different way to think and a different way to work. IMHO, I think it requires considerably less mental capacity to work in a TDD way. However, on the other side of the coin it requires considerably more training/experience to do well. You definitely want to decide upfront which way your team wants to operate, but I'm not about to say that you're "wrong" if you pick a different approach than I would. Anyway, thanks for doing the summary! It was very evocative for me :-)