The Bad Apple: Group Poison | Hacker News Reader

The Bad Apple: Group Poison

codinghorror.com

40 pointsbdfh4218 comments

I really hate reading Atwood. His writing is generally boring, but I can deal with that. The problem is that random phrases are emphasized for no reason. Is his readership so dumb that they won't be able to extract the main ideas from his article with them being in bold?

Anyway, it really annoys me. I wish Steve Yegge would blog more often and drown Atwood out :)

I thought that was off-putting at first too. Then, I tried it on my own blog, and I see why he does it.

The difference in engagement was clear. More on-topic comments, lack of questions already addressed in the post, lower bounce rate, longer time on-site, etc.

You have to write for scanners. The majority of your visitors aren't looking to read essays or blocks of text.

The theory of this is almost twelve years old:

http://www.useit.com/alertbox/9710a.html

And the data haven't changed much:

http://www.useit.com/alertbox/percent-text-read.html

This blog post put me off of Coding Horror forever: http://blog.wekeroad.com/blog/nothing-to-say/

He's jumping to conclusions. "Get rid of bad apples" sounds horribly intolerant. In the real world it is possible that the pessimist, the sceptic, the unmotivated or even the jerk may just see a problem the others don't want to aknowledge.

It's just as easy to jump to the opposite conclusions: a bad apple makes a group question the validity of its goals. A group who spends time making sure its goals are worthy is bound to be less productive, but is more likely to do the right thing.

Well, I think there's a distinction. He's saying people a bad apples are people who are skeptics, unmotivated, etc. but do not suggest anything better.

If they're skeptical of your idea or whatever, they should add constructive input instead of dragging on everyones spirits.

Just playing devil's advocate, but why would that person have to have a better idea? A person doesn't necessarily need to be in possession of good ideas in order to be able to sniff out bad ones.

Though I admit, it would be weird if someone can tell an idea is bad, but not be able to say why. In that case I think the detractor deserves to be ignored on the grounds of insufficient proof.

If there are bad apples in a team, they deserve some kind of presumption of innocence. The manager should at least try to find out what's wrong. I've seen bad apples who were frustrated because they weren't listened to, and they did have good ideas which they could explain. In those particular cases I did not witness how this situation developed, but I have no doubt that bad management can produce bad apples.

All you can say about bad apples is that they point to a problem. To fire them without asking is shooting the messenger.

I think part of the point was to recognise if you are being the bad apple, and changing attitude, thereby "getting rid of the bad apple".

Certainly seems consistent with what I have experienced (I see myself falling into the "depressive" dysfunction from time to time, and I know plenty of people who could be #2).

In my experience, there's a good and bad way to do it. There's a huge difference between bringing up negative points and whining or complaining. My rule was always - If you've got something you've got issue with, propose some action with it.

I found myself breaking the rule and complaining about East Coast weather a lot. So I then amended it to, "I hate this weather. I'm moving to Spain or California in the next year", then I took gradual steps to set myself up for it. Then I went to Barcelona, spent some time there, and now I'm in Los Angeles. "This project seems to be sucking huge manhours - I wonder if there's a way we can outsource the real grindwork here?" --> Very, very cool. "This project seems to be sucking huge manhours. I hate this. This sucks." --> Totally not okay.

A group of 4 with one deliberately undermining a group is 30% less productive. Now 25% of that is obviously just the 1/4 people not performing. Interesting to see that the individual productivity of the other team members was affected less than 2% each, which suggests that the larger the group, the less effect the "bad apple" has - it's not the case that the behaviour spreads out of proportion.

That's not really correct, if they'd lost 100% productivity instead then each person wouldn't have been (75 - 0) / 3 = 25% less productive. Dividing like that's not valid.

Indeed. They should have produced e.g. 400 productivity units (lines of code <gd&r>?), but lost 30%, i.e. 120 units. 100 are due to the bad apple, the remainig due to lost productivity of the other three. So each if them only produced 93.333 units, for a loss of 6.667% of individual productivity. Which is 233% more than 2%.

Yes. But isn't this just a corollary of a (small) group being more than the sum of its parts? IE, A group of 4 should be more than 4/3 productive than a group of 3. The right comparison is to compare a group of 4 with one bad apple with the productivity of a group of 3.

Yeah, the truth is somewhere between that and the other theory that the overhead for internal communication goes at least quadratic with the number of group members, so a group of four looses 16/9 more of their productivity to internal friction than a group of three.

And all this is assuming you actually have a quantitative measure of programmer productivity that is accurate enough to measure a 30% change. But let's no go down that drain again.

> A group of 4 should be more than 4/3 productive than a group of 3.

Why? Amdahl's law suggests otherwise, as does any non-zero cost of communications.

Because the knowledge and skill set of the group is larger. However, yes, at some point this is outweighed by the costs.

It's "Will Felps", not "Wil Felps". The paper itself is in "Research in Organizational Behavior, Volume 27", Google Books preview of the paper is available here:

http://books.google.com/books?id=RKkxJnn73UoC&printsec=f...

Reply on news.ycombinator.com