Best way to deal with 'bad apples'?

Question

In Jeff's latest post on Coding Horror, he talks about the "bad apple" effect:

What [the research] found, in short, is that the worst team member is the best predictor of how any team performs. It doesn't seem to matter how great the best member is, or what the average member of the group is like. It all comes down to what your worst team member is like. The teams with the worst person performed the poorest.

On a software development project, especially a large one, there are several things that need everyone's support: source control, requirements gathering, design, bug tracking, schedules, and so on. Looking back on my own software development failures, I can often find one single point of failure that brought the whole thing down.

And the terrible truth is that in a lot of those cases, it was one person that started the downfall. It might even have been me.

Jeff suggests that the solution to this problem is simple: just get rid of the bad apple. But sometimes this just isn't possible, especially in government and teams where seniority (or one of the -isms, like favoritism or nepotism) comes into play.

So my question to you is, how do you deal with the bad apple(s) on your team? Given that the research says that "if you can't beat 'em, join 'em" is the status quo and we know that doesn't work, what is the realistic alternative?

EDIT: I'm not talking about people with low skill, I'm talking about people with bad attitudes, like the ones who think they don't need to use SCM because they're expert coders, or the ones who don't want to fix bugs because it's boring, and so on.

Answer 1

We train and educate until they become better. If they are trainable – fine, mission accomplished. If they are resistant to training, it's a good evidence for the management that we really really need to fire or move them onto some other position despite of what good people they are.

Answer 2

Seconding SharpTooth - often the bad apples can improve quite a bit with the right guidance or training.

• Let the better developers mentor the bad apple. They might not like it, but if you show them the research background they will admit that it might be a good idea.

• Devise a training programme to address the most pressing issues.

• Do more code reviews to fix the bad apple's code before it turns into a "Broken Window" (see The Pragmatic Programmer book).

And lastly, move the bad apple to a project where the damage is less bad.

Answer 3

If you're the boss, make sure and build him up to any employer/other department head, so that maybe they'll hire him away.

Answer 4

This might sound a bit like getting around the problem but I honestly believe that the best you can do is not hiring them at all. In my experience, good HR people are surprisingly effective at filtering out bad apples during the interview stage.

If you cannot affect the hiring process or you already have a set of people in your team that poison the work of other members, then obviously you will have to deal with that situation some other way.

Answer 5

Give then a task, that is completely encapsulated, well separated from the rest of the application by well defined API.

Answer 6

Problems in projects come from everywhere from bad managers, spec, expectations, or execution. I'm sure that the following could be more in depth but here is the basic flow i try to work with when I'm in a team environment:

1. Review and plan out all the aspects of the project
2. Start project with goal points
3. Monitor that the goals are being met
4. When a goal is not being met then identify the problem with the team
5. Correct the problem or work with the design flaw to get the project over the finish line
6. Have a lessons learned about the project

The bad apple can then at the lessons learned can be told his flaws based on the observations made during the project. He has an opportunity to learn from his mistakes and move on. if the bad apple doesn't learn anything then that will be apparent in the next project and grounds for re-assignment of responsibilities or even being asked to leave the company.

Answer 7

It really depends on what they're doing. In many practical situations, you have no choice but to keep them (some government agencies, they have tons of knowledge, etc.)

The main differentiation between someone that should stay and someone that should go has nothing to do with their skill, attitude, aptitude, or desire to do a particular kind of work. If they're interested - even remotely - at improving themselves, then they're workable. If they're low skill but bright, let them learn. Give them tasks that they're good at, and slowly expand their area of coverage.

Hates bugfixing? Have them write unit tests, or code close to the bugs. Make sure to review their code, point out problems. Give them situations where they have to eat their own dogfood. Make them encounter bugs on a regular basis, so they want to fix it.

Hates working with others, but brilliant and wrote the core library that your company is built on? You can placate them, for the time being. I remember reading a story about such a situation; the junior engineers in the company in the meantime rewrote the core component entirely, making this one competitive advantage obsolete for the engineer. It did not end well for him...

Doesn't like source control? Make sure that two or three people all need to work on the same file as the guy who's not using SCM. Make sure you're constantly stepping on his toes. If he's always losing changes (by accident in the course of natural events, I would NEVER advocate doing this on purpose) he may start to see the advantage. If you happen to be working on the same file as him all the time, he may see the light. If that's not enough, very little you can do about this in any honest way. In the most dire of situations you can can always 'arrange' for poorly timed power outages once or twice a week.

Never compromise. Never sink to their level. That's just bad sportsmanship, and will look terrible on any other job application. "Yeah, we had this bad egg in our group and instead of working with the situation we just let it go on."

Answer 8

You need to find a role for them that is useful to your team.

This can take many forms: you can retrain them, you can mentor them, he can write unit tests, they can deal more with the customers, there are a number of roles in your team that they can do.

In one team, one person wasn't really fitting as pure coder, so he was moved to deal more with customer technical problems. For him, this was really a good move, he enjoyed it more, and the other coders got more work done :-)

For the SCM problem, there are technical solution(s) to that. Remove the rights for him to do anything BUT change source code through the version control system. This can be enforced through a process, using continuous integration for instance.

If you have coninuous integration, then this will do a full check out from source code control, (so to get code into the system, they have to check in). If, say, your integration cycle was every ten minutes, then it would be very hard for them to change anything permanently If you have a production platform, then make sure all changes to that production site go through a person (not him).

Make sure that the management know what you are doing, and promote it in the name of quality, stability and control over the process. (This is a good thing anyway).

Pretty much anything that you suggest to the management can be promoted as 'process improvement' or 'quality'. Code reviews? Quality. Source Code Control? Quality. Continuous integration? Quality. Defined processes for moving to production? Quality. Only doing builds from the SCM system? Quality.

Hope this helps.

Answer 9

Wow, very interesting topic,

I can think of two examples where I've noticed a bad apple in a dev Team that I have worked on. Without getting too specific, (dunno if either of them are actually on SO) the first actually ended on very positive note, the second on the worst case of the negative (a firing).

In the first case, the developer had a loud mouth, was egotistical, and did some very un-ethical stuff behind the company's back. The actual affect that this had on the team was that it made for somewhat of an anger-filled, untrustworthy environment where the other developers were spending 15% of their time thinking about how much they couldn't stand the guy rather then thinking about their work.

The turn-around; Our manager at the time tried to form a stronger bond with the guy on a more personal level and gave him the lead on some of the more important projects that were on the plate for the team that could be performed by a single dev. The manager hung-out with him during breaks and did not single him out the way the rest of the team did. After a while the manager was able to convert the guy's negative energy into positive, and he actually became one of the most productive members on the team.

Developer #2 was not so successful. At another company there was a developer who had been one of the more tenured engineers on the team and was very adverse in our efforts to progress the technology we were working on. This developer avoided confrontation but was extremely sarcastic and when asked to help out on a project would agree to the work but would then either leave early or not finish the work at all. Eventually he was fired.

In retrospect, I think the biggest problem with #2 was that he needed training in the new technology (we were moving from asp to .net) and he needed the manager and the rest of the team to give him positive reinforment when he completed a task using .Net. The problem at the time was that we were doing a huge push to redesign the system and no one really had time to work with him as much as he needed.

I think in his case Jeff's "Bad Apple" effect was in full force and I'm not quite sure there was any other way to deal with the situation.

Answer 10

Cancers love healthy tissue. So, remove the cancer. Treat the cancer. If incurable, read the writing on the wall. Do not let cancer spread.

Answer 11

First of all, all members of your team must document their code. Because if your member doesn't document, you're dependant on this person for explaining how his/her pieces of code work and how to code other things that interact with that code.

You don't want an irrepplaceable coder, because once they realise they cannot be replaced, they make themselves expensive as hell.

Second, everyone should work with the same editor. Simply because this is the best for team-interaction.

Third, everyone should have a small program on their machine which allows them to compare text-documents. So they'd know if something changed while they were away.

That was technical, for team-management, always have your team members create 1 or 2 hour sessions in which they explain their code to eachother and can ask eachother questions, check their code, adjust things, etc...

This way, the entire team has a sense of how the project is going.

There's probably more, but that's all I could come up with right now.

Answer 12

In "This American Life," episode #370, Ira talks to Will Felps who has done actual research on Bad Apples on group dynamics. It's well worth a listen.

Will found that Bad Apples had a significant effect on group dynamics. However, he also found that the presence of an exceptionally strong leader could negate the effect of a Bad Apple.

So if you can't get rid of the Bad Apple, you may be able to minimize their damage by bringing in a strong leader.

Here's the actual research paper. (I love you, Google Books!)

Answer 13

Joel already answered this. I have seen it work.

the rubber room concept works fine. Basically you give them something to do that does not affect anyone else. It is expensive to carry someone who is not productive. but it is cheaper than having them ruin everyone else and the projects they work on...

Answer 14

The "Bad Apple" isn't all that bad. If you have all brilliant people around there is less of a measuring stick for their skill level and it becomes easy to over-estimate them (and for them to under-estimate themselves).

It's important not to have too many bad apples and not to put them in places they'll spoil the apple crumble.

To top that off, most bad apples aren't pathologically bad. They just need to learn, and having a bunch of brilliant people mentor them can polish them into good apples fairly quickly. If they're incapable of learning from their mistakes and the tutoring of others then there is only one other option; they have to go.

Answer 15

The first step is making sure they are aware they are a bad apple. Many people are just so used to bitching about everything they don't even realize they are poisoning the well.

Another good step is to stop participating in the rot. As surely as a single person constantly bashing a project can bring it down, a single person remaining solution focused can bring things up. You also have to let people know you are going to be solution focused and not problem focused and you have to work hard to maintain that focus, even leaving side conversations that are poisoning the well. In meetings, you can start asking "is that really leading us to a solution". You will have to alter your words from time to time, as the same statement over and over again has reduced effectiveness and people start labeling rather than listening.

As for government, etc., you can get rid of the bad apple. Getting rid of does not necessarily mean firing. The best way is to find a new app for them to work on alone. Unfortunately, this is often impossible if either a) management is the bad apple or b) management will not pasture the bad cow.

Answer 16

Speaking as a boss, I've done two things to "deal with" bad apples:

1. Isolate them
2. Fire them

Negativity and counter-productiveness are like a bad disease, treating it as such (quarantine then eliminate) are really the only solution.

Answer 17

Biggest bad apples I've seen have been managers with lack of technical skills, often an almost complete lack.

I've almost never seen a coder who I thought had a bad attitude.

The very best way to deal with this is to try to eliminate them in the hiring process.

If you have one on your team? Try to make peace with them, what do they want out of life? Is there some way to make them happier and more productive?

If all else fails...I guess try to relax and not worry--there are probably much bigger problems at your company if they want to keep people like this around.

Answer 18

• a rolled-up newspaper, properly and repeatedly applied to the nose, accompanied by the phrase "Bad Developer!" spoken strongly in a stern tone of voice, is a good first approach at correction
• if this does not improve the behavior, then a time-out is appropriate: five minutes watching HR training videos alone in the break room ought to be enough to start
• if no change in behavior is observed, public ridicule may be required, "So, Mr. Apple, if fixing bugs is so terribly boring perhaps after you've fixed a few you'll be less inclined to code them and check them in without running the unit tests."

be sure to praise him/her for any step in the desired direction, no matter how small; this will help the puppy developer get the right idea, and keeps up his/her motivation

if none of the above works, then as a last resort you can sit him/her down and lay it out: "You're bad attitude is bumming out the team, dood! Get with the program or find another job. You have one week to comply. In the meantime, you will have no assignments and no interaction with the rest of the team."

Answer 19

Find out what's got the bad apple so pissed off and attempt to rectify that.

They don't do it because they're evil, they do it because something is bothering them.

If that doesn't work, or you don't have the authority or knowledge, attempt to redirect them onto a project that "they can be in charge of" or something. Ask them to do something for you that only they can accomplish. Something independent of your project and that no harm can come of.

Answer 20

You have identify what makes them a bad apple and your recourse is predicated upon that person's issue:

• A consultant who is not open to good input from team members because of ego needs to be dealt with quickly. Ego run rampant is BAD, it will kill off the incentive of your best, steadfast resources. That's called your team. The consultant is not part of your team. Get over your man-crush / "this-person-is-so-brilliant" / "wow-your-so-incredible" and get rid of that consultant.

• A team member who is Kazoo from the Flintstones - "No dum-dums, you fix it" - needs to be called Kazoo, publicly, and teased relentlessly. By the manager, too. "Kazoo, time amongst the knuckle scrapers will do the dum-dums some good. Besides, you're still stuck on this planet, so deal with it."

• A team member who is afraid of new technology can be easily handled. Challenge and simultaneous praise will turn their weakness into a strength. If that individual has been with your team for a good period of time, it's worth it to treat their attitude as potential feedback: is there something at work that they don't like but can't bring themselves to express to the team? A good team will rally - quietly and privately - to change for the better. This may or may not entail doing what the bad apple wants, but it will entail seriously listening to misgivings.

• A team member with "bad habits" can be nicely "cajoled" into better behavior. 5 people against one can use humor to retread a bad tire. "And the answer to why this code isn't checked in is anybody, ... anybody, ... Jerry?" If you get a middle finger back, the manager needs to step in. Most people do take kindly to gentle teasing. Keep it gentle.

• A team member who is a whiner needs help to focus on results first, then cry over beer later. Ignore HR when they come and say that the "feedback" needs to examined. This pyscho-babble BS only exacerbates the situation. Constant examination of why something sucks is a big time downer. "You know, you're creating deep neural pathways with that mantra. Let's get this done!" is always a good phrases. Or, in the words of my battle seasoned father "Who gives a shit?!!?. Ignore it and let's move on" is also a good dose of reality. If the whiner is still looking for therapy, the manager needs to step in with a stern "You got this stuff done yet?"

• The Dr Who team member who won't share the code for the sonic screw driver needs to meet Davros, the manager, and not make it to the next incarnation. Don't put up with it period. Treat the Doctor like Kazoo, as they are really an Earthling with a big scarf and are indeed mortal.