I agree that Collective Code Ownership is not able to expose poor programming, but then, there is no way to expose poor programming at all. Unless, of course, the management can review the code written and have the knowledge to tell good code from bad code.
But the IT management normally won't have the time, or the ability to conduct code review. The management, well, have to do lots of managerial stuffs. And reading code isn't exactly fun. Which is why we have code peer-review, in which you have your own fellow developers who review your code and you review theirs. It's kind of self-checking mechanism here.
In the process of code review, defects will be fixed, and the slower developers can learn a few things from the good developers. Sure, the good developers can get frustrated with the poor code, but at least they get a chance to fix the code base sooner rather than later, when the slower developers leave. The important points of code review are that
- Defects get fixed sooner
- Poor developers have mentors
Well, it is entirely possible that the management doesn't know the performance of both Bob The Poor and Gwen the Great. But this is not so much of Collective Code Ownership's problem. Rather, it's management problem because telling a good developer from a bad one is always a management problem.
The management will not know that bad developers are a drag on a team, regardless of whether the team practices pair programming or not, unless it is actively listening to the developers and the developers have the gut to tell the management the truth and the management has the wisdom to tell who is a good developer and who's not in the first place.
This is a hard task for management, especially for the management who are not good software developers themselves. But still, blaming management's inadequacy on an agile practice is not exactly fair.