My Secret Life as a Spaghetti Coder
home | about | contact | privacy statement
Aside: It was tempting to satisfy my desire to entitle a blog post using two clich├ęd proverbs and an OrColon: Subtitle, but I refrained from calling this "Bad Apples Don't Always Spoil The Bunch, Or: Don't Throw The Baby Out With The Bathwater." I also could have used the subtitle, "Or: A Four Course Meal To Avoiding Disaster On Your Team." Such titles are great for posting to reddit/programming, but I've had enough cheese today on my pizza.

However, so that I don't neglect the cheese lovers among us who have a craving for the moldy substance, I'll tide you over with this morsel:

Appetizer entertainment from The Osmond's aside, we can get to the salad plate of our four course meal: Jeff Atwood wrote a blog post about Dealing With Bad Apples where he quotes some of Steve McConnell's work:
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.
He goes on to quote McConnell's reporting of the data (something valuable McConnell always offers):
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).
All of that is to say: software developers with bad attitudes should not be tolerated for long, lest they destroy the team from the inside.

He continues, citing ways in which to identify miscreants on your team, finally concluding that
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.
There's nothing too striking here. In fact, I didn't think twice about it until I read Brian Cunningham's response:
I agree with this wholeheartedly. But you also have to ask yourself whether there's something you could have done to prevent things from getting to this point.
Whenever a bad apple is discovered on your team, you should always consider the possibility that it could have been prevented. In many cases there's nothing you can do -- it's simply a conflict of personalities. But if you find situations where the bad apple could have been prevented, that means there's something in the management of the team that needs to be addressed. (Strong emphasis mine)
And then Jeff's words stuck out, reminding me of me:
You can develop skill, but you can't develop a positive attitude.
In my case, it was me who decided to develop the positive attitude. But that doesn't mean it couldn't have been developed by a skilled manager who noticed the problem.

Retrospective action is useful in avoiding the problems of today in the future, but often misunderstandings, miscommunication, and a lack of clear goals or motivation can be the cause of friction or a bad-apple attitude. So I take it a step further to the main course of our meal: Not only should you reflect on how the problem could have been averted upon discovery of the subversive, you should actively scan for potential problems and address them before they germinate.

It would not result in firings or team destructions, but instead focus on resolving the conflicts before they fully emerge. (Of course, if the problem is allowed to grow and fester, firings are encouraged.)

I'm not sure how to do that.

I don't personally have the answers regarding strategies for identifying problems and understanding what people really mean in conflict resolution, but I'm confident they exist. I've read as much. But I searched the all-knowing Google and didn't find the sources I sought. So at the moment, they remain outside my realm of knowledge. Therefore, I'd like to ask: What are your strategies? How do you handle problem developers or teammates? What are the reading materials discussing these issues that I'm looking for?

I supplied the dinner. Can you provide us with dessert?

Hey! Why don't you make your life easier and subscribe to the full post or short blurb RSS feed? I'm so confident you'll love my smelly pasta plate wisdom that I'm offering a no-strings-attached, lifetime money back guarantee!

Leave a comment

There are no comments for this entry yet.

Leave a comment

Leave this field empty
Your Name
Email (not displayed, more info?)


Subcribe to this comment thread
Remember my details

Picture of me

.NET (19)
AI/Machine Learning (14)
Answers To 100 Interview Questions (10)
Bioinformatics (2)
Business (1)
C and Cplusplus (6)
cfrails (22)
ColdFusion (78)
Customer Relations (15)
Databases (3)
DRY (18)
DSLs (11)
Future Tech (5)
Games (5)
Groovy/Grails (8)
Hardware (1)
IDEs (9)
Java (38)
JavaScript (4)
Linux (2)
Lisp (1)
Mac OS (4)
Management (15)
MediaServerX (1)
Miscellany (76)
OOAD (37)
Productivity (11)
Programming (168)
Programming Quotables (9)
Rails (31)
Ruby (67)
Save Your Job (58)
scriptaGulous (4)
Software Development Process (23)
TDD (41)
TDDing xorblog (6)
Tools (5)
Web Development (8)
Windows (1)
With (1)
YAGNI (10)

Agile Manifesto & Principles
Principles Of OOD
Ruby on Rails

RSS 2.0: Full Post | Short Blurb
Subscribe by email:

Delivered by FeedBurner