XP vs. OOP
XP says don't design and code for reuse until reuse is needed. Don't spend money for something until you need it and until you know just what you really need. This goes against one of the holy grails of object oriented programming (OOP), but it is a reflection of how things work in the real world. This is in line with XP's basic philosophy of simplicity: Do the simplest thing that works; and don't design or code for possible future requirements.
Another sacred cow of OOP is the ability to delegate responsibility to an isolated modular object or API, and hence, the ability to delegate work to an isolated, modular, cubby-holed programmer. In XP, however, not only are programmers required to work in pairs, they are required to eat in groups, sleep well, develop basic social skills, and, one would assume, bathe. In addition, all team members are free to mess with others' code. While individual areas of expertise may be thinner, groups no longer find themselves overly dependent on any one individual.
Then there is bad code. Bad, untested, overly complex, buggy, inefficient, unformatted code. Code written by "the other guy." In the world of XP, tests are written before functional code is written, code is written in pairs, and anyone on the development team is free to refactor and/or rewrite anybody else's code. So there is no longer an "other guy" and, as a result, no bad code. One can only hope.