What about taking the team into account? Programming projects are rarely done entirely in isolation; so how do you measure performance of an entire team? And who is to blame if it all falls apart? Missing deadlines is part of life, and as we've seen in a previous lesson: we are very bad at predicting when we will finish something. But companies, institutions, and classrooms all still seem to value some kind of performance metrics, and it is a very valuable ability to predict that kind of thing. This study tries to see if personality type affects how people pair program. Pair programming is where one person is the "driver", holding the keyboard and typing. The other person is the "navigator", dictating how the problem should be solved. If you've ever done pair programming with a random person from class or your TA or the guy down the hall, you know that it is a total crapshoot of an experience. Perhaps you work like a well-oiled machine, vibing with each other like the best of friends. Perhaps it's a big old disaster and you end up writing all the code yourself later or feeling entirely inferior, and getting reminded of being forced to watch your older sibling play video games while you didn't even have a controller. Pair programming can be, and should be, an amazing tool we use to collaborate and solve problems together. But it's hard to work together and that's not just a software thing.
http://neverworkintheory.org/2011/07/26/effects-of-personality-on-pair-programming.html
Maybe we could match people by personality traits to make pair programming more effective? This study indicates that doing that is just not a fruitful avenue to go down, and we should focus our efforts somewhere else.