I'll try to summarize the good answers here in hope of a good & comprehensive answer, see if it works:
1. Define "performance" well
First, be sure about your definition of "below average" or, to put it less politely but more honestly, "bad performance". There's been plenty of articles discussing how most performance metrics are of little use in our trade (and in knowledge-based organizations in general).
Also remember that it's the performance of the whole team that counts and if you have someone who doesn't get much code done but is a great guy and keeps morale high and everybody loves him, he is actually being productive. These things are practically impossible to measure and you need a very reliable "gut feeling" and a lot of very open and direct contact with your whole team.
2. Find the real reason for low performance
Once you really have established that members of your team have a negative impact on productivity, it's important to find out why. Do they stay behind expectations because they (a) aren't smart enough, (b) are not yet experienced enough or (c) there are cultural or political issues in your team that get in the way or mess up motivation.
(b) is easy to fix, just arrange for proper mentoring and they'll be up to speed soon. (c) is harder but is also a very serious problem that management alone is responsible for and which should be addressed. (a) really means the tasks they are doing are too hard (yet). Find something easier to do and give them opportunity to expand their capabilities.
3. Almost always, avoid firing like the plague
Firing people in teams of 10 is very, very expensive and might well have bad unexpected side effects, such as dragging down the morale of others. Although keeping bad performers on board although "everybody" knows they aren't contributing can also bring people's morale down, as Jeff Allen rightly points out in the comments below:
Firing boat anchors is a critical part of respecting and nurturing your best performers. If everyone knows someone is not cutting it, seeing them cut loose can make the team fly.
I think, firing people is on the management scale very similar to rewriting code from scratch, it's very tempting (in the sense that it seems straightforward and liberating), but you just shouldn't do it. And then, sometimes, it still helps, which led me to add:
4. It is also important to fix your recruiting process
I basically copied FogCreek's recruiting strategy (apart from the limo at the airport, so far) for my own two companies and have been told by colleagues and friends also working in software development that
"you'll never get enough developers if you require them to in-place-reverse a string in C, on paper, during the interview - I don't know, if I could ... - I mean, who even still uses C, these days"
Which seems right, I never have enough developers. But I'm happy with those that I have, and I hope I'll always have to worry about getting more instead of getting rid of team members.