I'm mixed on unit tests - there are some things the developer will know (white box) about edge cases etc. that others likely wouldn't, and they should definitely have input on those tests. On the other hand, independence of review is a very important aspect of "harnessing the power of the team." If you've got one guy who gathers the requirements, implements the code, writes the tests, and declares the requirements fulfilled, that better be one outstandingly brilliant guy with all the time on his hands he needs to do the jobs right. If you're trying to leverage the talents of 20 people to make a better product, having them all be solo-virtuoso actors working independently alongside each other is more likely to create conflict, chaos, duplication, and massive holes of missed opportunities and unforeseen problems in the project.

I really disagree here. If someone else is writing your unit tests, that means one of the following is true:

• the tests are written after the code is merged - there will be gaps, and the second dev will be lazy in writing those tests
• the tests are written before the code is worked on (TDD) - everything would take twice as long because each dev essentially needs to write the code again, and there's no way you're going to consistently cover everything the first time

Devs should write their tests, and reviewers should ensure the tests do a good job covering the logic. At the end of the day, the dev is responsible for the correctness of their code, so this makes the most sense to me.