text:
Robert Miesen sent in this story of a project pathology:
I was part of a team writing an web-based job application and screening system (a job kiosk the customer called it) and my team and our customer signed on to implementing this job kiosk using Windows, Apache, PHP5, and the ZendFramework -- everyone except one of our team members, who I will refer to as "Joe". Joe kept advocating the use of JavaScript throughout the technology deliberation phase, even though the customer made it quite clear that he expected the vast majority of the job kiosk to be implemented using a server-side technology and all the validation should be done using server-side technology.The fact that the customer signed off on this, however, did nothing to deter Joe from advocating JavaScript -- abrasively. Every time our project hit a bump in the road, Joe would go off on some tirade on how much easier our lives would be if we were only writing this job kiosk in JavaScript. Joe would constantly bicker about how we were all doing this all wrong because we weren't doing it in JavaScript, not even bother to learn the technologies we were actually using, and, whenever fellow teammates would try and gently bring him back into the fold (usually via email), Joe would just flame the poor guy. At the height of Joe's pro-JavaScript bigotry, he would regularly belt off comments like, "Well, if we had only done it in JavaScript," to such an extent that the team would have been better off if he had just quit (or was reassigned or fired.)
After reading this story, I had to resist the urge to lean forward, hand placed thoughtfully under my chin, brow furrowed, and ask -- have you tried JavaScript?
Robert thought this story was a cautionary tale about technology dependence, but I see something else: a problem team member, a classic bad apple.
I'm sure "Joe" had the best of intentions, but at the point where you're actively campaigning against the project, and working against your teammates -- you're a liability to the project.
The cost of problem personnel on a project is severe, as noted in Chapter 12 of McConnell's Rapid Development: Taming Wild Software Schedules.
If you tolerate even one developer whom the other developers think is a problem, you'll hurt the morale of the good developers. You are implying that not only do you expect your team members to give their all; you expect them to do it when their co-workers are working against them.In a review of 32 management teams, Larson and LaFasto found that the most consistent and intense complaint from team members was that their team leaders were unwilling to confront and resolve problems associated with poor performance by individual team members. (Larson and LaFasto 1989). They report that, "more than any other single aspect of team leadership, members are disturbed by leaders who are unwilling to deal directly and effectively with self-serving or noncontributing team members." They go on to to say that this is a significant management blind spot because managers nearly always think their teams are running more smoothly than their team members do.
How do we identify problem personnel? It's not difficult as you might think. I had a friend of mine once describe someone on his team as -- and this is a direct quote -- "a cancer". At the point which you, or anyone else on your team, are using words like cancer to describe a teammate, you have a serious project pathology. You don't have to be friends with everyone on your team, although it certainly helps, but a level of basic personal and professional respect is mandatory for any team to function normally.
Steve outlines a few warning signs that you're dealing with a bad apple on your team:
Let me be quite clear on this point: if your team leader or manager isn't dealing with the bad apples on your project, she isn't doing her job.
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.
Removing someone from a team is painful; it's not fun for anyone. But realizing you should have removed someone six months ago is far more painful.
Its hard dealing with someone whoe isn't productive, has a negative personality etc... Yes you need to address the problem as quickly as possible. First in foremost though, you need to avoid getting in that situation. A good hiring process will be your best defense. Always check references, always do your research. If someone is a bad apple, they probably have a history of it.
I think another good thing you can do is involve the team early on in the selection/hiring process. Its a lot easier to be critical of someone when they are just thrown into your group without having a say. Its also a lot harder to find problems with people when you were a part of the decision to bring them on.
Rob on July 18, 2008 2:41 AMI generally hire using the NUTs (southwest airlines) philosophy... Hire for cultural fit. I would much rather have a good fit personally than get the best Java/C#/Perl developer. If the basic skillset is there and they mesh with the team, I'll pick them over the 4.0, CS/Software engineering applicant that can't function in a team setting.
I have also used the term cancer to describe a co-worker. Unfortunately, he is my bosses friend and has been in the organization longer than anyone else. Since I can't remove him in any legal manner from the group, I (and about 30 others in the last 3 years) have decided to move on from this place. August 1st is my last day.
The project will continue and even improve over the next few years, but it could've been so much better without this one person. oh well, guess it's no longer my problem!
Wayne on July 18, 2008 2:57 AMO/T, I know, and probably also asked and answered at some point, but: how/why do you post yesterday's post today? I'm always flummoxed by the appearance of a new post dated yesterday, when I've already stopped by this blog at least once itoday/i. I don't think there's any place in the world where it was still 7/17 when the 7/17 post went up...
Ah. Probably some sort of limited-scope post-reviewing feature where you have some trusted few people check out a post before it goes live? And the timestamp doesn't update when you hit Publish for real?
Chuck on July 18, 2008 3:00 AMhuh... people like that don't need to be fired or even disciplined... they usually just need recognition that they have skills that are not being utilized...
Yes, its possible to do it in JavaScript, and yes, we're glad that we have someone like you with mad JavaScript skillz on the team... but the client said server-side code, and he's paying the bills... and I need to keep this client otherwise I have to fire people. So we have to wait patiently until the next project to push JavaScript, k?
bex on July 18, 2008 3:06 AMAll these cautionary tales have the opposite effect on me, I think that would be a nice problem to have.
I've just escaped from a place where all the developers complained about each other to all of the other developers; the managers complained about their own developers to the client (WTF!); and the developers complained about their management to the client!
Dysfunctional isn't the word. I did suggest just locking the front door and calling it an asylum. Such was the state of the place that that comment wasn't out of place.
B Cash on July 18, 2008 3:18 AMWe have had this on our team before. Our problem bad apple was someone stuck in a programming mindset of well over 15 years ago and more importantly deathly afraid of anything remotely new. Having been hired before any of us, he had been able to convince management that his world view was actually still how it was. I was actually in a debate comparing the performance reliability of an Oracle database against a dBase file.
What is worse, all problems that were had for sometime were blamed on new technology. Database corruption (dBase) blamed on that new Win Server 2003 SP2 server it's on for example, Win 2k was suggested because it had a better file system. Things like this completely frustrated the hell out of the rest of us.
Communication was also a problem, emails sent from him reminded me of a 4rd grader learning to type for the first time. Almost incomprehensible - 20 sentence paragraphs, missing important punctuation, or the exact opposite (overkill), and spelling anything over 5 letters was a challenge. But management just wrote it off as he's busy!. Now we had to decipher what exactly he needed us to do. Worse, he was near silent in meetings, and could never explain his position or why something "wouldn't work". It was useless interacting with the guy, and I can tell you very honestly we all tried our best.
I wish I could say there was one thing that finally convinced management that this guy was really something time forgot and a dud. (We actually thought he had naked pictures or something) It took several years of pain before people started realizing that projects built that didn't involve this guy actually worked, usually timely - and more importantly didn't have to be debugged for a few months after release.
If I did have to pick one turning point, it was when we realized as a team that these old programs processes this guy had worked on for years, while always seemingly complex as they constantly errored out, produced bad data and the guy was up all hours of the night working, were actually quite simple. We took the source code, and started porting them into our new environment - and quite simply made them work. We were actually shocked at how little code they guy actually had written over the years. We were expecting well over 75k lines to deal with, and it ended up being less than 15k. It was completely void of any internal validation, everything had to be perfect for it to work besides relying on a huge set of assumptions. Overall, we went from 15k to about 24k. He called it a waste of time, bloated, and wanted management just to ignore it, but we convinced them that there was nothing wrong in letting us at least test it.
In short, our ported new and validated processes completed nearly 2 hours faster and produced correct results. This used to be a 5 hour process. We didn't get to know we were correct for another 36 hours, as magically - the old process broke in front of everyone (as we always knew it did privately) and took a full day and night to correct in production. After our CFOs review - ours balanced - his did not.
Publicly he resigned. We could easily have been 2 years ahead of where we are today if he hadn't slowed everyone's progress. His world was filled with fixed rigid rules that even a slight temperature change would break the system kept everything held back to the lowest common denominator.
@Chuck: Wow, I didn't even notice that! Oh god, we're living in the past!
Adam on July 18, 2008 3:39 AMAh but sometimes its the team leaders/managers who are the problem, and the complaints from the other team members that continue load into the night are the voices of reason. Sometimes its the apples, sometimes its the basket.
codist on July 18, 2008 3:41 AMBut seriously, makes you wonder what sparked this entry.
This 'secret' is revealed in the first line of the post: Robert Miesen sent in this story of a project pathology...
Can you really call it a spoiler when it's the very first scene of the movie? :)
Jeff Atwood on July 18, 2008 3:50 AMI have recently just been pulled out of a project for a bad case of bad-apple-itis, and although I certainly didn't like it, I admit that it was necessary, as we had a 3-day timeframe to deliver.
A lot of the time, the bad apple isn't aware of what they are doing. One of the big problems is that they feel like they haven't had their say considered, and when you hire people in industries based on intelligence and aptitude, that's a mortal sin.
My biggest problem is that I don't usually have a clear scope of what we are doing, so what I think is me discussing new approaches is actually me wandering off into oblivion.
In my personal experience on both sides of this, I'd say a lot of the time the leaders need to step in much sooner than they do. I've seen a lot of groups crumble simply because the leader was only leading those following him/her, and wasn't making an effort to corral the wayward, other than to tell them to stop being disruptive.
There are going to be those in a group that need special attention to keep them in line. It's usually just as simple as TALKING to that person and finding out what's happening.
And don't patronize them either; you're there to settle them and turn them around if you can. If you can't, then you need to take real action before they start becoming a regret.
TechBender on July 18, 2008 3:51 AMWell, i see your point, but i must say, the only way to respond to criticism sent via email is with a good flaming. honestly, i can't remember the last time i agreed with criticism sent in an email.
I give you a bit more leeway if you talk to me in person though, mainly because i don't have my trusty keyboard to use as a weapon (sharp pangs to the heart with witty comments, or a mildly hurtful blow from it's blunt surface, you pick).
Darren Kopp on July 18, 2008 4:03 AMI've seen this happen a lot over the years. Only twice was the cancer treated by some means other than surgical removal.
On the first instance, we had a lot of bad apples in the company. It was so bad that management brought in a team of industrial psychologists to analyze us individually and as a team to find out what was wrong. The fix was to introduce a series of meeting norms and organizational processes for the project. It worked (along the way I found out I'm an ENTJ on Myers Briggs).
The second instance we had a guy who just couldn't *listen*. He was always forming a counter argument. Always. You could see the counter argument taking shape before the other guy was even finished talking. He was always talking past the other person. This guy had to be privately challenged to listen. In fact, the manager forced him to use active listening techniques. He wasn't allowed to present any counter arguments unless he could demonstrate that he understood what the last guy said, and the only way to do that was by repeating back in paraphrased speech. (That technique is used by marriage counselors on people who are very argumentative.) He was cured.
In all other cases, I've seen the cancer removed.
Charles on July 18, 2008 4:08 AMI've been that bad apple, disagreeing with bad practices and voodoo programing.
If you cant change the place you work, change the place you work. Go somewhere else.
We're paid to solve problems. If your team doesn't give you the slightest consideration and listen to the points you make, they don't know how to solve problems. The inability for a team to give a valid and sound response to Why Not, is a clue they suk.
Unreasonable men force their surroundings to fit them.
Reasonable men change themselves to fit their surroundings.
Thus all progress is made by the unreasonable.
The warning signs for bad apples something are very loud and clear, developers asking for random days off with 1 day warning without giving a reason is very frustrating for everyone on the team.
However, when does it go from someone who just has a different way of working everyone else or that they should be voted off the island, or worse?
Another warning sign I think is when they talk about projects they did 10 years ago on completely different requirements and think everyone should follow the same approach.
Ben Hall on July 18, 2008 4:09 AM... a level of basic personal and professional respect is mandatory for any team to function normally.
I used to think I suffered from being the bad apple - but not for any reason other than because my skills are simply on par, they're nothing genius-like or even /good/ often suffering behind those that are really good at what they do. Then I realized, that skills can be honed and improved upon, which I'm still in training for :) - but basic personal skills and professionalism is where I make up for lack of tech skills... it's absolutely crucial for team cohesiveness, even if a team member is not that good skill-wise... we had a bad apple on our team recently that also quit recently. Everyone complained about that person because they simply would not keep their mouth shut and argued everything. Relief set in when I showed up one day and without a goodbye, that person was no longer with us - and if they're reading this, so long; but it's the truth.
Great and relevant article Jeff, cheers.
Patrick on July 18, 2008 4:14 AMIn fact, the manager forced him to use active listening techniques.
A great story. How I wish we were all lucky enough to have managers this smart and effective! If you get only one thing out of this post, it is this:
If you're the team leader or manager, dealing with bad apples is YOUR JOB. And if you are not actively doing it, you're causing your own project to fail, even though you may not be able to see it.
If you work on a team with a bad apple, you can gently prod the leader/manager to do their job -- maybe if you're truly desperate not-so-gently go over their head -- but unfortunately that's about it.
Jeff Atwood on July 18, 2008 4:17 AMSometimes it's the other way 'round - you're the one good apple and the rest of the team are the bad ones.
For example, my current employer began migrating from Delphi to C# over a year ago, and things haven't gone too well because the senior staff desperately attempt to apply their Delphi worldview to the .NET Framework, with predictably poor results.
I've told them numerous times that they're going about things in entirely the wrong way - using the wrong technologies for the job, or misusing the correct tech - and that hasn't exactly endeared me to the team. But given the choice between being the bad apple and being correct, or just another good, yet wrong, apple, I'd much rather be the former than the latter.
Thankfully, they are starting to realise that just because I'm a junior doesn't mean I'm always wrong. :)
The_Assimilator on July 18, 2008 4:35 AMAssimilator, see:
Also, I agree with some of the other commenters, above; if you find yourself constantly the odd man (or woman) out with highly diverging opinions from the rest of your team -- maybe you're in the wrong job. I mean that in a *good* way, mind you.
See also, Changing Your Organization (for Peons)
I have worked in places where I was a superstar, I have worked in places where I was a bad apple. The difference? The places where I was a superstar had flat organizations, where everyone had a voice. The places where I was a bad apple were places where the manager knew best.
As a manager, I have also had to deal with bad apples. I never got rid of any of them because of personality, though I have gotten rid of a couple because of simple incompetence.
What you are essentially saying is that the only role managers can play in dealing with bad apples is to get rid of them. The reality is that managers more often than not are responsible for creating the bad apples. Simplistically, people get frustrated if they are not respected. People get frustrated if they are not listened to. The fact that you have bad apples in your group reflects on your skill as a manager.
So, really, to the majority of the engineering managers out there: Get educated! Would you hire a person in your team without an engineering degree? Why do you think that you can be a good manager without having studied it? Being a manager is not in your genes, it is a skill that you have to learn, just like engineering was. Learn how to deal with your people, including your bad apples. You might actually find, like me, that a bad apple is better than most of the sheep you hire.
If you manage him right, that is.
Donald Duck on July 18, 2008 4:43 AMThe bad apple thing can go boths way. Some teams will label someone a bad apple when they don't fall in line, or conform with the team, when that person is fighting for the best interests of the project.
I've seen this a lot in environments where nepotism runs rampant. Where being buddies is more important than the success of the project.
Adam on July 18, 2008 4:46 AMWhat if the bad apple is not a team member, but rather your team lead? This is the situation I am in. My team lead is pretty close to useless. He is like the headless nail - once hammered in, he's nearly impossible to get out. And because he's been here waaaay longer then me, the powers that be are not going to rock the boat. I like the quote I read above - If you cant change the place you work, change the place you work. That might be my new motto.
Actually, there's no might about it. I'm gone.
Diomedes on July 18, 2008 4:47 AM@ Donald Duck
Bad apples are bad for a reason. Sometimes that's incompetence, sometimes that's their managers, but sometimes apples go bad because of where they're kept. Apples need to breathe, people need to be heard.
I think your first response was the correct one: After reading this story, I had to resist the urge to lean forward, hand placed thoughtfully under my chin, brow furrowed, and ask -- have you tried JavaScript?
You were giving the person a voice, a person who probably thought he was fighting for the best interests of the project.
Being a manager is like being a parent. You don't throw a baby in the garbage when it doesn't behave.
Adam on July 18, 2008 4:53 AMThis blog would be *sooo* much better if it allowed JavaScript in the comments...
@ Shog9
It would be even better if it allowed PHP in the comments. And you don't know what you're talking about. :P
Adam on July 18, 2008 4:58 AMNot being a team player is learned behavior, reinforced by management. Managers are usually so clueless most don't learn anything until one bad apple causes real damage.
PaulG. on July 18, 2008 5:02 AMIt's probably also worthwhile to note that there is a distinct difference in-between people who are capable of being bad apples (in the truest sense of the team scope, meaning that they in some way negatively impact the team) in SOME instances, but not chronically.
Some of the other comments have mentioned this, but to go into a little more depth, some people don't always react to different levels or kinds of stress in the same way, and some people won't even react consistently to the act same amount of stress on a daily basis.
The post made me evaluate my role on my team and where and when I've been a bad apple (which thankfully retrospectively SEEMS to be far less often than when I've been a good contributor) and the causes of it. If there are no 'third-party' influences of your 'bad apple' status (i.e.; predisposition to dislike you in management or cliquish behavior/nepotism, or any other kind of generic 'high school environment') then you should always be open to considering what causes these reactions and find your own personal workarounds for them.
My professor once said: When you fire your worst employee, give him the best recommendations so hi can go work for your competitor
Roman on July 18, 2008 5:16 AMthey usually just need recognition that they have skills that are not being utilized...
It's not that simple. People are way too dynamic to just rest on the bounds of We know you're good, but
It really takes some will and determination toward dealing with bad apples. In short, you really need to study their life a little. You need to find out if there is something else going on that drives as the fuel to the problem.
Dealing with bad apples is absolutely horrible experience, but leaving them to spoil the rest of the team is far worse. If you see a bad apple, make note of it and pass it on to your leaders. Listen to them. Talk to them. Just don't simply ignore them as a lost cause because they ticked you off. Half the battle trying to figure out if the bad apple is spoiled for good. And you're not going to figure it out by standing by praying that somebody else takes care of it.
And for the love of all things sacred, don't solve character problems over the internet via e-mail. You're just asking for a cake of misunderstanding. Find time (after work? *gasp*).
Read up on Maslow's hierarchy of needs. It's weird how much sense it makes after you've had to endure bad apples in your life.
David McGraw on July 18, 2008 5:26 AMSo, I guess I'll play the bad apple here since everybody else is just too impressed with the way you're stating the obvious - or too lazy to actually switch brain on while on the interweb.
Aside from the no-brainers that you cited (for the trillionth time or so, echo, echo?) there's also a slippery slope in there that you chose to leave completely unmentioned:
In every organization there will always be one person who knows what is going on. That person must be fired.
-- Conway's Law
At least point 4 and 6 in your list are very slippery because they can just as well (and in my personal expirience: at least as often) indicate a broken team/organization rather than a broken individual.
Honestly, how often have you seen software projects completely screw up? I mean really completely, from A-Z by all metrics. If your answer is anything other than quite often then you must be living in a different universe or just don't get out very often.
Your bad apple list works in reverse in these doomed projects. I'm doing consulting gigs for a living and thus have witnessed quite a few of that kind.
I'm on the team that gets called in right after $important_but_difficult_person was walked out the door but - oops - management failed to notice that this very person was pretty much running the show. We even have a name for that, it's the Clueless CEO vs eloquent CTO-Scenario. We call it that way because most of the time you'll find an technically less than adept but very talkative CTO that suddenly can't deliver anymore when the incognito workhorse was removed.
So, I'm not saying that bad apples don't happen or are not harmful.
Just don't forget to inspect (read: listen to) your suspected bad apple very thoroughly before dropping him out.
I had this problem on a project back in college. It wasn't even something important and the jerk had t fight the entire group about it. Basically he wanted to force everyone to use Hungarian notation on the project, because they used it at his previous internship and it was just so much better. Nevermind that most of the group had never even heard of it, OR that our school had it's own standards we were supposed to follow...
In the end we just gave him a section of the project to work on and the rest of us worked on the rest. Unfortunately we lost points for not effectively working as a team... :(
What happens if the bad apple is the project manager himself? certain doom?
Reonarudo on July 18, 2008 6:16 AMRight on, Jeff. :-) This is so true, and something that I see all the time. There are some people who are never going to get better and they just need to emgo/em.
Max Kanat-Alexander on July 18, 2008 6:26 AMUnfortunately this is particularly difficult to address in an academic setting. I've found myself as team leader on projects with some bad apples, but when you're doing it as part of a research experience, senior project, volunteer diversity in computing project, etc., being team leader does not give you the authority to take someone off a project. That authority is usually held by someone distant or unapproachable, and in the interest of learning (even when it's not class-related) you have to drag the bad apples through the entire process, slowing down your progress and degrading the quality of your work.
I hope that many of my peers do a LOT of growing up before they get to the real jobs, because if they don't they will not be well-liked and they will not be successful.
lauren on July 18, 2008 6:31 AMWhat happens if the bad apple is the project manager himself? certain doom?
Quite certainly so, yes. Bad management has many times been the doom of really interesting and good projects. See Borland/Delphi and Netscape as most famous examples.
I have some bad-apple potential myself, as I'm rather rigid about the use of certain tools. But I've learned to leave the other devs alone with it - as long as people allow me to do most of my code work in Vim and not force me to use too many GUIs to code, I'm fine.
One thing about the code reviewing remark, Jeff: there's a nice allegory: There is no (good) novel (or scientific paper, for that matter) without a decent editor, there is (nearly) no good musical album without a producer, there is no good code without a reviewer. People have to just accept that. If nobody reviews your stuff, you're stuff's sure to contain errors. Maybe your name is Donald Knuth and you can give everyone who finds a bug in your software a cheque (in fact, if you deny review of your code, you should be *forced* to do so), but chances are, you're not Donald, and so you'd better hand it in so someone can have a look at it.
This should be mandatory standard in industry and academia, as well as in open source. I'm quite frustrated that it isn't... (although I'm sure finding good reviewers is hard).
The second instance we had a guy who just couldn't *listen*.
At my fraternity I have a friend that is *exacly* like that, he study chemistry and don't know almost a thing about computers, but he just can't accept right away anything that I say about programming (or anything else) at all. He always has a (usually inconsistent) counterargument to say and takes forever to prove your point. Fortunaly for all developers, he study chemistry, not computer science. Anyway I will try those tecniques to make him listen.
Hoffmann on July 18, 2008 7:45 AMI completely agree that you shouldn't be DOGmatic in any choice of tool. But I hate to see my baby (JavaScript) always DOGged.
But of course, you should never rely on JS for validation.
Justin on July 18, 2008 9:12 AMI work in a large team of developers with one bad apple. That bad apple has been here rotting for 14 years (I've only been there 3). He has the ability to bring any meetings or discussions to a screeching halt. Any productivity can be ruined in just a few minutes of idle conversation about how we will all be laid off next week (a saying he's been using for 14 years since he was last laid off).
A negative attitude for whatever reason will ruin everyone else's day. I'm currently looking for a new job due to his bad-apple-itis spreading to a few more people lately and that is not an environment I can tolerate.
But seriously, makes you wonder what sparked this entry.
If your team leader or manager isn't dealing with the bad apples on your project, she isn't doing her job.
So... there is a woman involved, too? :)
a developer asked for the day off.
For some autistic people, this seems to be a no-go.
I say the contrary: If a day off is a no-go, then something in the team is going terribly wrong.
In good projects, where every team-member has at least one substitue, it should be no problem to allow a day off. If you have to think about such cases, you should think what you have done wrong.
A day off is only disallowed one day AFTER a new launch - despite all testing, some things will show only then :-(
titrat on July 18, 2008 10:47 AMBut can the team leader avoid the bad apple? A bad apple can be a good apple that got bad. In this case the team leader is also not doing her job if she doesn't communicate properly with her team and doesn't avoid getting into a damaging situation by setting clear expectations early. This way, an apple can decide to accept that path, quit or (hopefully not) become a bad apple. I'm sure that most of the bad apples didn't have that chance and became bad without knowing it and thinking they where doing the best for the project and that they could change it's direction for better. It's irrelevant if she was right or not. A bad apple could be a very good apple in another team. And the opposite is also true.
Of course, a bad apple could be just bad from the start in wich case you shouldn't have hired her.
Apple on July 18, 2008 11:24 AMWe wouldn't even have this conversation if we all used JavaScript.
And that's JavaScript, no Javascript like how everyone uses it.
When you are managing projects you can choose to use a carrot or a stick, the trick is knowing when to apply either one.
The case study you have presented uses plenty of sticks, but I see no carrots.
Most conflicts tend to be two very stubborn people refusing to budge an inch.
Having a team member that has not bought into the project will often result in net negative code (another wonderful McConnell term).
When faced with this problem I tend to use a positive approach at the beginning rather than attempting to thump the person into submission.
If the team member truly believes that JavaScript is better than give them the opportunity to prove it. Let them build a small sample using the technology and then compare it to the PHP/Zend sample.
Three things can happen.
1. They fall on their face and aren't able to make anything work (the usual scenario).
2. Surprise, surprise, they present something amazing (very rare).
3. They cobble something together that barely works but isn't efficient or workable or is in fact a security risk.
First two scenarios are extremely easy to deal with, and the second one is awesome. Third one can be measured with metrics and performance statistics.
What you call a bad apple MIGHT be considered thinking outside the box by others.
One of my teammate kind of becoming a bad apple. Despite his big talking about design patterns and stuffs, his codes are 'over-designed' big ball of spaghetti that has too many inheritance all over the places. It almost impossible to change anything without ripple the effects in large scale. Things are getting more and more complicated when we have to integrate everything together and he refused to change his coding styles. Though I knew all his intention was for the good of the project itself, I think the main reason was his lack of good understanding of good designs.
So I think, the bad apple might not be aware of his being the bad apple. From his point of view, he might be the one that trying to do something great and that no one is understanding him. I don't think dropping the bad apple out is fair for him and it's something the team lead should step in and try to turn him the other way around.
mm on July 18, 2008 12:39 PMI am very happy at my present job for precisely the reason that bad apples/duds get the ax quite fast. It's high end consulting work and not everybody can do it. It takes top notch people skills, deep technical expertise, and the humility to do some very low end stuff to get things done. We interview very thoroughly, but a few undesireable people still creep in.
My boss gives them one chance to fix themselves. Most are gone a month later. On occasion, they take it to heart and fix the problem.
Not to say that these people are all dirtbags (some are), but that not everybody is cut out for the kind of work we do. I'm sure they could succeed in another job with differing expectations. There's no use in keeping them in a position that they won't be successful at. It's painful for both parties, but also ultimately beneficial for both.
Matt Lentzner on July 18, 2008 12:54 PMI was that guy 13 years ago. Went from a company using relation DB's, to a a place moving from btrieve to MS Access. Their biggest complaint? Access doesn't have arrays. I tried to explain basic relational theory to the people very senior to me, only to be met with the same complaint. In the end - the problem was me. No matter how much I thought I was right, I should have have kept my mouth shut. Sometimes fitting in means leaving a finding a place where you share a like mindset.
john on July 19, 2008 2:26 AM
Bad Apple in the original example was half right - to the extent that client-side Javascript would have been useful for preventing some obvious crap from being sent to the server in the first place - but totally wrong in thinking it could replace server-side validation.
The question is never which to use, it's whether to use both or let the server do all the work. Any web-based app that trusts that data coming in has already been been validated is a security nightmare waiting to happen.
jneil on July 19, 2008 2:28 AMA very good post there jeff, never thought of it before.
Tushaar on July 19, 2008 2:35 AMJeff - Don't *ever* work for someone else where the coding standard uses #region's :)
I think we all have the potential to be bad apples - right now it may be me with respect to a recent decision by management regarding a problem-tracking tool-set. However, in that case I don't think the final decision has been made and I therefore think it is appropriate to be clear on my reasons against the current choice.
Charles mentioned Myers Briggs personality analysis, and it is often considered good to get people into a team who do NOT match the personality type of those who currently staff it. And at team or company level, you probably have experience of sales teams who seem to be a frequent IT bugbear - because they do and say things that at some level seem distasteful to us - but we nevertheless (probably) need them so we have work.
My point being that sometimes it is important to challenge our own beliefs with a different perspective. If we all think and code the same way, can we be open to alternatives?
That said, to harp on about stuff, even if we BELIEVE IN IT, after the 'decision day' will understandably have a negative impact and should be stopped by managers.
Nij on July 19, 2008 2:43 AMRemember the post about bashing fellow devs for using #regions just because you don't like them?
And who's the bad apple now, Jeff? :)
Tomek on July 19, 2008 3:25 AMSometimes you cannot just let go of a bad apple, even though it the the right thing to do. For example when dealing with a buyers market of technical skills it is extremely hard to find people with the right skills. On top of that you have the investement that is made when you bring them onsite.
These two factors make you work really hard to coach the bad apple. When the bad apple cannot be coached then the hard decisions have to be made.
This is coming from personel experiance. I have a bad apple on my team today. He cannot be coached, but I cannot find a qualifed resource to replace him. Even if I could then it would take about 12 weeks of investement to make this person productive. In our management team meetings we discuss this delima almost weekly, we know we need to throw out the bad apple, but we cannot!!!
Jeff on July 19, 2008 4:28 AMHello from a bad apple.
I've been a bad apple for 2 years in a software development firm. I just couldn't integrate into the insanity of the team. And by insanity I mean real insanity. Everything was done wrong, the stuff that was done right was overcomplicated and had too many bugs, etc. Every suggestion I made (before shutting up) was either rejected or implemented in such a horrible manner that I refused to take the credit for it.
Jeff, have you thought about that? That the team is loony/broken/insane/fine and dandy in their collective madness and the newcomer is trying to point it out, but in the process he gets to be the bad apple for not fitting in.
For two years I did what I was told and kept my mouth really shut. Then I got fired. That was the best day of my life.
Marko on July 19, 2008 4:33 AMa developer asked for the day off.
For some autistic people, this seems to be a no-go.
I agree. We don't know the context here except that it was before the launch.
But: before the launch ist often synonyme with a lot of overtime. So I'll take this as a scenario:
I myself find it horrible shortsighted to heap overtime on overtime for the teams sake, hooray, hooray.
If the member wants a day off to clear his mind and do , give it to him. He'll be of more use the next day.
If denied, only solution as developer is: put yourself into a position that you just have to take the day off, because of . Your boss might frown, you colleagues will understand.
Krischan on July 19, 2008 4:53 AMSometimes bad apples happen because the manager promotes his ex-IBM buddies. Writing on the wall here.
Overcome bad apples and massive egos with strong management or get other developers to grow a backbone. Seriously sad when people have to deal with other people with a school yard mentality. These people are on a team for a reason. The complainers are part of the team too. If they don't call out the bad apple they are bad apples also. Fire them all.
I'm currently in a team of two working on database access through the web browser - generally we work well together but I do find my team mate doesn't really input many ideas into the project, he seems to readily accept mine but then when I check to see whether he's completed his bit so we can integrate components, it's usually something completely different to what we agreed!
silence on July 19, 2008 5:27 AMHi, the point I would like to make concerns the simple firing of people.
Firing people can be incredibly difficult in some countries and the work and effort needed to manage someone out of the team (and therefore out of the company) can be real drain on everyone's time and energy. Even through you know it is the right thing to do, it becomes a very time consuming process. The last thing you want to be dealing with is a work tribunal. You often have to prove that the work of the bad apple is not to standard and prove that the person is aware of quality of work needed. Next there is the warnings needed; first verbal warning, then a written warning before dismissal.
Of course, when the bad apple is verbally warned or given a written warning, they can become a jobs worth and just do exactly what is required and nothing more. It this point you hope they jump ship, but if they want to dig their heals in the ground then the cancer and really set in.
Reorganizing the team so the position no longer exists and offering redundancy means a) you can't create a new position for a length of time and b) a loss of moral as the rest of the team see this behavior rewarded with redundancy money.
The moral of the story is - Don't do anything without HR being involved. Otherwise you can leave yourself open to being sued and that can also wreck your companies image of being a good employer and heap a whole load of stress onto you. In fact the whole process is stressful but you have to believe in what you are doing.
Courageous managers confront the bad apples on the their problem behaviors. The cliche says that people never change, but I have seen bad apples reform themselves in response to being taken to the woodshed.
Josh on July 19, 2008 5:49 AMBad apples in the IT industry still stun me. Were they all excused the week of kindergarten where we were taught how to get along? I don't care how smart you are, how much of a stick in the mud, how opinionated, whatever: talk to people like they're human beings, not strange fleshy manifestations of IrCbots.
Katie on July 19, 2008 7:02 AMActually the thing that annoys me most and I see it as Bad Apple Syndrome, is a team member that doesn't update/commit to version control enough. I think you have to update at least once per day (The *whole* project) and committing should be whenever an important milestone happens/when the code works/at the end of the day but only the working bits. At my workplace we have a few people that allergic to updating. About once per week they will have a problem and mention something like, Oh have you noticed this bug? and I will say Yes, we fixed that 3 weeks ago, why don't you update? and they will say Which file? and I will be like *$#*@#$*(%#*##$(*#(*!!!! and my head will explode.
Chris Pilkington on July 19, 2008 7:36 AMGood post. I find a similar thing is resistance to change, especially in the case of internal applications. I used to regularly suggest little changes just to cut those extra couple of minutes to my boss and the return was always well it works already. After I had been there a while I just started doing them without asking. Low and behold the users are much happier.
pete on July 19, 2008 7:36 AMGood post. However, I make the point that it's become increasingly more difficult to fire (or even at times reassign) bad apples. It's in fact infuriatingly difficult.
I've known many great leads who don't have the ability to do that, because of HR concerns or management concerns about liability. It's sad, but true. When you don't have the support to be able to show bad employees the gravity of their behavior to the point of removing them from the situation, you're left playing more ambassador than leader.
I was a bad apple where I worked previously. I was doing technical support and was getting bored and frustrated with dealing with the same old bugs that stayed around for many releases. Aside from doing customer facing support, I was also supporting our installation staff who were equally as burnt out from being over worked and under appreciated. I finally wore down and couldn't take it anymore and went from being a happy worker to a burnt out husk after having snapped at a teammate. Since we had recently had a management shake up, my old boss was trying to help me move to another department where he felt I'd fit in better. He knew I didn't belong in technical support and he knew I would be happier elsewhere.
My new boss, on the other hand, didn't care. He scheduled a meeting and presented me with his suggestion which was simply, Why don't you go read a book? He ended the meeting shortly after without bothering to suggest what to read or even where things needed to go. A few weeks later I was still unhappy and burnt out when I got the dreaded call from HR.
My point in all of this is that sometimes bad apples are management's fault. I would have been fine had I been moved to a different department. But my manager didn't care about the person. He only cared about what made him look better.
I really think companies need to start giving people the benefit of the doubt and working with a person finding out WHY an individual is a bad apple before they throw said person out the door. I think most of the time the problem is fixable. Most people don't like conflict. They don't like being unhappy. These things are all fixable with a bit of time and care which is ultimately cheaper than firing someone, going through the hiring process, and training a replacement.
That said there are some true bad apples but I honestly believe they are few and far between.
Jay on July 19, 2008 9:03 AMWe have this problem with our MANAGER. He has been with the company for 6 months now. We are an AS400 shop and he comes from the Windows world. Well so do I but you have to adapt because programming on the 400 and working for this company is what is paying the bills right now. He is not even a real programmer - his background is in networking but he learned .Net along the way.
The problem is he doesn't want to learn anything about the AS400 or any of the technology we use. He has even referred to is a stupid and crap right in front of the development staff.
We are currently looking for a change management tool that will do version control and every time we have a demo or talk about what a company can provide for us he says things like .Net has been doing that for the last 15 years. We have even heard him say to people outside that company that we use AS400 but that is not the direction we are going in which is news to the rest of the staff. The problem with this is that I doubt he will train the current staff but instead replace them. That is of course if there is anyone left.
I lead a team of a couple hundred engineers and I can tell you that finding out about bad apples and weeding them out is a serious concern. It need to be done, but like pruning a garden it can be hard to see and needs to be done with care.
First you have to setup an environment where people will tell you the truth (and not just what you want to hear.) That's not always as easy as it looks, many managers get promoted because they are viewed as tough by senior management. Tough (I prefer tough but fair) can be good, but tough sometimes means reacting poorly to truths. If you do that, you train your team not to tell you the truth until it is too late.
Then you have to hope that your team shares the truth about a bad apple with you. You aren't in all the meetings and you don't hear all the bickering or snide comments. You might see an email or two if somebody gets upset enough to copy you, and if you do you have dig under it. Fight the temptation to pass it off as a one-time event. I figure for every action I get to see, there are 10 more I don't. Hopefully by keeping your eyes and ears open - along with your door - you'll catch wind of a problem.
And of course you have to find a way to be fair to all. Yes you have to handle the person who isn't fitting in, but it isn't as simple as firing them - at least not in large corporations with liability concerns. Sometimes you have to assign them to one-man projects. Sometimes you have to move them into a place where they will fit. And yes, sometimes you have to ask them to leave.
My story is from the leaders perspective. I was hired in to lead a team and soon found one of my managers was toxic. His attacks on other team members and blowups in meetings when decisions didn't go his way were hurting the team. He fought like a wildcat to get all the perks for his team that he could, but openly denigrated teams run by peers. These antics were tolerated by previous management (although I couldn't ever figure out why.) Even senior management knew he was hard to work with; I was constantly asked what I thought about him by my boss. Eventually I realized they were hoping I would take care of the problem. I had to take a few months to get my bearings, but eventually I sat him down and told him it was obvious he was unhappy - given all the attacks and anger - and it was time to find another spot. He tried to say it was just his style and I should accept it. When I said flat out that I wouldn't, he got the message and moved on.
Phred on July 19, 2008 9:19 AMI have to think that there's some things wrong with how this post plays out. I mean, the example given isn't a very good one, given that Javascript, used properly, would most certainly have improved the project as far as its use and reception by its users—who are most certainly not the clients. I happen to think that the obnoxiousness of the bad apple as described is probably half hyperbole and half real but reactive to the poor decision to make the application less usable than it could be.
Reading the post, I noticed that I am technically a bad apple where I work—correction, at the business of which I am part owner. We're small and all of us are learning, but I am certainly the only one on the team who knows a damn thing about good practices when it comes to software development projects, software quality, usability, even source code management. And the reason I'm fighting my team on these issues is not because I'm a zealot for, oh, I don't know, cleanly written code, safe handling of user input, good UI, source code versioning, or anything else; it's because we're suffering for a lack of such zealotry on the team as a whole, and it makes all of our lives harder.
It makes our projects harder. It makes us spend more of our hours working against ourselves and one another, and less of our time enjoying things in life besides work.
It's not hard to see all of this as analogous to being outspoken about things much more important than what technologies we choose to use in our daily work; for instance, it's impolite and unpopular to go into a Wal Mart and speak out against sweatshops, it would not make you many friends. But it's absolutely the right thing to do (speak out, that is; Wal Mart might not be the most effective venue for that, however), and every day that any of us doesn't speak out against things that are clearly wrong is a day we put off improving the lives we touch and even our own lives, partly to simply avoid being bad apples. I'm not bringing this up as an opportunity to turn this comment into my own personal soapbox, only to put it into perspective: sitting idly by is decidedly not a universal virtue.
There are ways of being effective and ways of being obnoxious, however, and it sounds like the worst offense the bad apple in the example given committed was having poor judgement about how and when to speak up, and poor interpersonal skills. While that might be uncomfortable in some ways, I hardly think it's something that deserves much in the way of scorn or punishment.
Trevor on July 19, 2008 11:03 AMI don't think I get what you mean about #6 - was him taking time off going to make it impossible for him to finish his deliverables for the deadline? 'cause it sounds like you're saying that his choice of activity (buying cheap mens clothes... wait, why is the gender even significant?) was what didn't fit in with the group.
matt on July 19, 2008 11:10 AMI think it comes down to the fundamental problem of programmers: We're always right, ESPECIALLY when we're wrong. And many of us have to get our opinion out there. Do you read all the comments to a blog post before you throw out your me too?
To me a bad apple is someone who doesn't listen or communicate well. There are times when the best technology choice isn't the best business choice. If you refuse to compromise on why a source control repository isn't worth the overhead on this particular one-off 20 line script, then you better coach it in terms that make sense for the argument against. The earlier comment about active listening techniques was great. I think one of the best things any dev can do is to restate the argument they're arguing against before launching into a rebuttal. So often we find ourselves talking past each other because we're not trying to understand what's being said.
On a personal note, I have a dominant personality, and so does a teammate. I have the utmost respect for his work and ability, but we both always have to have the last word. Even when we're in vigorous agreement, we'll take exception to some trivial detail here or there. The intelligent thing to do, of course, is to shut my damn mouth.
SteveJ on July 19, 2008 11:52 AMI love how everyone has their stories.
Mine consists of needing to get rid of the bad apple and the CEO kept undermining me NOT to fire the guy. Well after a few months and a stack of papers full of reasons to fire the guy the CEO finally gave in.
But wow, I'm the boss of this guy and I want to fire him and when the CEO (Doesn't even work directly with this guy to know his performance) keeps undermining me to keep in on staff, it lowers my moral.
Lucky for me I'm out of there now though, when my decisions are not respected, I take my skills somewhere that will give proper respect.
Scott on July 19, 2008 12:13 PMIt is unbelievable, it's like you took the words out of my mouth.
I totaly agree, those situations lead to a very negative attitude in the team and after some time, it is too late because the cancer has spread to the whole team.
I have always hired people who;
1. Have interest in the technology.
2. Show some interest in the actual work.
3. Are able to communicate to a reasonable degree.
4. Can do the actual work.
It's extremely easy to call someone you don't like a bad apple just so people can have their little parties. Lots of managers seem to hire based on making themselves (feel) more important.
In the more vertical management structure you tend to find its somewhat overloaded with (useless) sycophants, while in a flatter structure you end up with weird (somewhat unlikeable) people who are busy doing the job rather than kissing up.
Next time I hire a plumber for a week long job should I have the family interview him to determine how well he will fit in?
Should I hire the guy again to do more work based on how well he got along with everyone or the quality/cost of his work?
I agree it is nice to work in a pleasant environment with people you get along with but I am not convinced the quality of the work improves.
Jeff you sound like you have hit middle management and are trying to make work comfortable while you sit in a dark place surrounded by friends in your own territory.
Even from your own post;
more than any other single aspect of team leadership, members are disturbed by leaders who are unwilling to deal directly and effectively with self-serving or noncontributing team members.
Unfortunatly in this era of the non-confrontational workplace managers deal with problems by whinging about them (to others) and calling people bad apples.
Wally on July 19, 2008 1:18 PMI have always hired people who;
1. Have interest in the technology.
2. Show some interest in the actual work.
3. Are able to communicate to a reasonable degree.
4. Can do the actual work.
It's extremely easy to call someone you don't like a bad apple just so people can have their little parties. Lots of managers seem to hire based on making themselves (feel) more important.
In the more vertical management structure you tend to find its somewhat overloaded with (useless) sycophants, while in a flatter structure you end up with weird (somewhat unlikeable) people who are busy doing the job rather than kissing up.
Next time I hire a plumber for a week long job should I have the family interview him to determine how well he will fit in?
Should I hire the guy again to do more work based on how well he got along with everyone or the quality/cost of his work?
I agree it is nice to work in a pleasant environment with people you get along with but I am not convinced the quality of the work improves.
Jeff you sound like you have hit middle management and are trying to make work comfortable while you sit in a dark place surrounded by friends in your own territory.
Even from your own post;
more than any other single aspect of team leadership, members are disturbed by leaders who are unwilling to deal directly and effectively with self-serving or noncontributing team members.
Unfortunatly in this era of the non-confrontational workplace managers deal with problems by whinging about them (to others) and calling people bad apples.
Wally on July 19, 2008 1:20 PMWhat do you think about pyhp?
Will it be a valid - more 'elegant' - substitute for php in opensource server-side web development?
All this blog entry is saying is that a team member that acts poorly has the ability to effect a more negative influence than the positive contributors. One Bad Apple Spoils the Bunch .. hmm already a cliche, I guess it must already be a part of human collective knowledge, and I'm betting that this cliche is applicable to more than just IT slaves.
You can be a jerk, but only if you're smart and are never wrong, which is easy when you're a TV character.
house on July 20, 2008 3:51 AMbut only if you're smart and are never wrong, which is easy when you're a TV character.
Another lesson from Gregory House, M.D. -- every user lies:
In a bad management situation like this, this is what YOU do. Do YOUR job and get it done QUICK. If the other person doesn't do their job, and you're caught up, show the boss what's going on and offer to do THEIR job (since you have nothing to work on at the moment and are all caught up). Eventually, the bad apple drys up, falls apart, and you get a raise because you're a God now.
car on July 20, 2008 5:50 AMIn your example there might be 2 cases:
1. The client said a good reason for not using javascript.
2. The client chose not to use javascript for a minor reason. He doesn't know that with javascript the project would be easier to implement, thus cheaper and would be ready sooner, and the project manager did not tell him that.
In case 1 the project manager should tell his team why they should not use javascript.
In case 2 the project manager has some fault, because he should have explained to the client the advantages of using javascript.
Usually bad apples appear because they don't know enough about the project or because of misunderstandings, which should be solved.
Jeno on July 20, 2008 8:10 AMshe isn't doing her job.
Got anything against women????
I wish I could fire my previous manager....but how to deal professionally with a manger who is more like a donkey than a leader?
Gov on July 20, 2008 8:44 AMWow. I knew developers were hard to work with in general, but this guy Joe takes it to a whole new level. The team dynamic is crucial, especially among smaller development teams. Everyone has to work together or the project will never get completed. Even the most difficult developers can be reigned in if their main goal is to launch a successful application.
John on July 20, 2008 9:53 AMI'm on the team that gets called in right after $important_but_difficult_person was walked out the door but - oops - management failed to notice that this very person was pretty much running the show.
And the only other people with helpful knowledge left when their friend got sacked.
tk. on July 20, 2008 10:43 AMThat's wonderful. Could you print this out, stand outside of a college graduating MBAs, and staple one copy to each forehead coming out?
Every technology job I've ever worked had one rotten member, maybe more. Even to the point where they'd start physical, punching fistfights in the office! Without exception, the management's response when the team complained about the bad apple was a shrugging oh well. Yeah, they'll talk to him. And that's all they'll do.
Penguin Pete on July 20, 2008 10:54 AMEven the most difficult developers can be reigned in if their main goal is to launch a successful application.
Well said. Everyone on the team should have one shared goal: to ship great software, not pursue personal agenda at all costs.
If you can't subsume your individual desires to the greater good of the project (and assuming you have the right job -- advancing the craft of software engineering in some small way), what *are* you doing, exactly?
Jeff Atwood on July 20, 2008 11:14 AMThe article is clearly wrong. The first three points are standard procedure for entrenching yourself within an organisation. Failure to keep your code private, and ensure that you are the only person who can do fixes translates to failure to demonstrate that you are vital to the organisation.
In fact, any developer willing to allow the absurdity of "open team development" to occur may as well be begging their organisation to promote another developer above them.
Okay – this is slightly facetious – but it is my experience.
It is surprising how many project leader don't do their job in that respect. I worked on a time where a team member didn't a fidget about the project. Hi didn't work on it full time, instead he worked on private projects during work hours and on staff meetings he would actively oppose any project improvements that would give him extra work. It the direct complaining of all of to make the project leader remove the bad apple from the team. And it wasn't fast not decisive. I had to complain every day for a month to be taken seriously. I showed evidence, the project leader said I was correct and he saw it too, but he didn't do anything until a more senior colleague complained.
Nikola Stjelja on July 20, 2008 12:30 PMThis is a very interesting article, from my personal experience, in some of the case at times bad managers are responsible for apples to become bad. The best way to deal such a thing is being a proactive manager than an reactive manager. I have seen and heard quite a few people who boast that they are a good managers and how nicely they treat their team members, but when it comes to pitching help they just won't do it even if they are busy doing nothing. To some extent such managers are responsible for programmers turnign into bad apples or bad examples or anyother lable you want to apply.
Anand.V.V.N on July 21, 2008 2:04 AMGreat thing about this blog is the Oprah effect; serious (technical) issues often degenerate into sociopathological discussion.
Cultural fit, bad apple, all nonsense.
Instead of culturally fitting people :), find people who are motivated and knowledgable. Knowledgable people tend to be relaxed in interviews and willing to share a lot of information in discussions. They are excited when they talk about they work.
IT dudes, on the contrary, are always looking at bad code, vacation schedules and endlessly whiteboard anything that should be coded already. Best practices beaten to death in the process.
Depth of Knowledge is inversely proportional to Depth of BS in every team.
I finished a little project while reading this post, btw. Getting the work done. Have you heard of it?
BugFree on July 21, 2008 2:09 AMGood post - I think it's important to distinguish between what constitutes a bad apple and what constitutes a considered voice of dissent. And I think it can sometimes be difficult for those occupying either position to know which position it is they are actually in.
In my own personal experience I found myself taking on a new job joining a well established development team and very quickly feeling like that bad apple. I was constantly highlight points in the application which were of great concern to me and I felt should be handled differently, contrary to the opinion of the rest of the team. In the end I removed myself.
However this only begins to gain context when it is realised that the points of great concern to me were that credit card details were accessible unsecured via the web. The rest of the team felt that the 'security' in place, namely a login for on a previous page (whose security didn't extend beyond that page) was adequate, despite the fact that a direct link would bypass this.
Sometimes it can be hard to stand up for your convictions in the face of derision from your peers.
MarkM on July 21, 2008 3:28 AMI don't know. Sometimes I've been that bad apple and sometimes I just wanted to be the bad apple because the leaders were just being rotten. I've been called ...not a team player. because I had the audacity to leave on time on a friday night. I got into a argument with my boss (an extreme A-type) because my performance put me in 3rd place even though he knew I should be in first. The other guys were willing to work until 10pm every night. I clocked out at 6pm, like my contract specified I was being for.
The other guys began to resent me because leadership was taking my rebelliousness out on them. They were all recent immigrants and I was the only naturalized person on the team. The problem is I knew what the company could legally get away with. I tried to tell my colleagues but they were so afraid it just made it depressing for all of us.
I eventually left after a few months.
Take a lesson from Trump...
Your're fired.
Its sad to think that the state of the art for team management has reduced to who do we vote off the island because the others don't like him. I think we could do with a lot fewer managers and we definitely need a lot more leaders. I don't care if you are a follow me lead by example or a spear carrier giving me the encouragement and tools I need and pointing me in the direction I should go type. Either is better then typical office drone promoted to management who has no idea what they are doing.
I have some times been the lone voice going against the group consensus. I've learned to state my opinions, give my reasons, and if the others are not persuaded to update my resume as we will all be looking for jobs after another failed project. Group think does not magically always find the correct answers.
Jim C on July 21, 2008 6:20 AMI'm one of the bad Apples :P That does not mean I'm not playing with the team. I use a database system at work, although I hate it (everyone does BTW), but our bosses love it. So we use it. We don't love it, but we use it and we learned to take it as a fact It is there and we have to use it; period.
Our current build system is XML based and simple actions I usually do with 50 lines of Perl codes need 900 lines of XML code in the system. I opposed to this practice multiple times, but I'm falling on deaf ears. It is there, it works, learn to love it.
It is one thing if you have customer requirements you need to accept (like in your example), it is a different thing if you have free choice, but the team settles down on a more than suboptimal choice. If I then hear arguments like We use it, because it is there, it is free, and it works, I can only think Wow. FreeDOS is there, too, it is also free, and it also works... so why are we using different operating systems? Maybe because they are *BETTER*? The steam train was there as well and it worked, still we developed trains running with gas or electricity, didn't we?
However, I stopped behaving as this guy did. It's pointless. Instead I pretend to be a nice team player and use whatever I have to use. However, in my free time I re-do stuff and do it the way I consider right. Once I'm done with that, I show the team what I have done and guess what, sometimes they say Yup, you are right, it's much better that way, and I have to refrain from saying Isn't that what I told you in the first place?.
Sometimes you are the bad apple. But sometimes you are the only fresh apple in a basket of bad apples. In that case it's best to go with the other bad apples. Make your opinion clear right upfront, but if your opinion stays unheard, go with the team, even if you dislike. It makes you a good team player to play with your team, even if you strongly oppose the team's decision. There is always a way to show them in the future how things can be better, but don't permanently tell them how bad things are, because they made the wrong decision.
Mecki on July 21, 2008 6:35 AMWe are all, in some way or another bad apples. Its been bred in us as technology people. Lets be honest, none of us were the coolest kids in the school(well I was, I dated half the cheerleading squad at the same time). But the rest of you developed an intense, screw you all I'm smarter than you'll ever be attitude to all the little fish in your little pond. Its a natural mental defense mechanism, and we've all got it.
Then we grow up and most of us learn to adapt to the fact that we're not as smart as we think we are, they are plenty of other people out there with ideas just as good as ours. Some programmers though, don't let that Screw you, I'm a genius attitude go. The javascript evangalist in this article sounds like one of those people. Unless you happended to double major in clinical psychology, there isn't anything you can do to help that person, and your best bet is to get them off the team.
WindyCityEagle on July 21, 2008 6:37 AMFundamental Attribution Error.
Look it up.
BTW, nice quote of Conway's Law, Bad Apple.
Kyle Huff on July 21, 2008 7:13 AMYou can develop skill, but you can't develop a positive attitude.
I see where you are going with this sentiment, but I disagree. I think there are a host of things you can do to nurture a more positive attitude including the development environment and taking the time to actually _listen_ to developers. Now if you have tried these and other methods and the individual still isn't working out, then I agree its best for them to move on.
Grant on July 21, 2008 7:33 AMWow.. This sounds so familiar.. I worked with a guy on a team that build Warehouse Management Software and a Wholesale/Retail website that would constantly bicker about if we had just used Java and other like quotes. This caused significant problems all over the team. His constant bickering was just dragging everyone down. Once it had gotten to the point that he was literally breaking something everyday just because the bullheaded way that he thought things should be done, it got too much. He picked up the warning signs soonafter and resigned his position... Smartest thing he'd ever done for us.
Matt on July 21, 2008 7:48 AMLets be honest, none of us were the coolest kids in the school(well I was, I dated half the cheerleading squad at the same time).
The male half? :-)
T.E.D. on July 21, 2008 7:54 AMJim Collins, in his book Good to Great, says one of the first principles of a successful leader is knowing who to put (or keep) on the team and who to kick off. (He puts it in terms of who's on the bus and who's off, but you get the idea).
a href=http://www.jimcollins.com/http://www.jimcollins.com//a">http://www.jimcollins.com//a">http://www.jimcollins.com/http://www.jimcollins.com//a
Chuck on July 21, 2008 8:13 AMWell, that link got thoroughly mangled...
just go to jimcollins dot com.
Chuck on July 21, 2008 8:14 AMI've heard that when it comes to hiring new people, it's preferable to hire a lovable fool than an competent jerk. It's easier to teach the lovable fool how to do his job better, but the competent jerk will always be a jerk.
Matt S on July 21, 2008 8:16 AMEasy to say, not easy to do.
Bad apples are unfortunately more like well rooted weeds.
A weed is impossible to turn into a flower (though some of them bloom), and uprooting the weed may damage other flowers, or even yourself with nettles.
You would think that poor reviews and poor compensation over time would give them the wake up call, but that is rarely the case.
The comments to this entry are closed.
Traffic Stats |