Bad Apples

You should never be afraid to remove -- or even fire -- people who do not have the best interests of the team at heart. You can develop skill, but you can't develop a positive attitude. The longer these disruptive personalities stick around on a project, the worse their effects get. They'll slowly spread poison throughout your project, in the form of code, relationships, and contacts.

- Coding Horror

I agree with this wholeheartedly. But you also have to ask yourself whether there's something you could have done to prevent things from getting to this point.

I've experienced a few bad apple incidents in my career: In one situation I readily admit that I could have been labeled as a bad apple myself (and rightly so). Having been on both sides of such a situation I've seen where it's not just the individual that's deemed the bad apple who can be at fault for letting things get so bad: In some cases the team itself can cause the bad apple to emerge.

I won't try to pass blame onto anyone for me being a bad apple: I realize now the mistakes that I made and use them as a learning experience. And I learned long ago that my way isn't always the right way and that sometimes just going along with what's been decided is better than trying to change things mid-stream.

That being said, their are situations where the team itself can be at fault for the emergence of a bad apple. For instance, a developer might get the impression that their input on the project isn't wanted, or even desired. This isn't a situation where a developer is just being pig-headed about some idea and being shot down continuously, but where a developer's ideas just aren't even being discussed or considered. If a developer gets the impression that the team simply doesn't want their input, that developer may isolate themselves and simply stop engaging with the team like they should. The situation then starts to head down the road to "rotten developer."

The key to avoiding this is to maintain solid communication within the project. This is the one thing that helps both prevent accidental bad apples from emerging, as well as finding the real bad apples like Jeff describes in his post.

Whenever a bad apple is discovered on your team, you should always consider the possibility that it could have been prevented. In many cases there's nothing you can do -- it's simply a conflict of personalities. But if you find situations where the bad apple could have been prevented, that means there's something in the management of the team that needs to be addressed.