Could an internal rep, voting and badges encourage good programming practices?

Question

Just thinking out aloud - we programmers love all this voting/badges/rep stuff so could a scheme like this be introduced into a companies code review process to encourage better coding.

Something like

• You (or others on your behalf) can post a review (could be snippet, single commit or series of) for a code review

• Others can comment on it (would be similar to answers in SE)

• Badges can be given/suggested (some would be good, some would be bad like "Comment Desert" or some such)

• You can vote up/down on the code itself and the comments and badges (e.g. if someone suggested a badge and you did/didn't agree)

The aim of a scheme like this would be

• Introduce a bit of fun to encourage the use of code reviews

• Improve quality (in this scheme both code reviewee and reviewers are likely to learn)

• Reduce the chance of code reviews sparking 'ego wars'

• Give some metrics to help measure individual performance

Could this work? Thoughts?

Answer 1

Extrinsic reward such as money, badges or rep will work, short term, like diets and any other reward/punishment based system.

Intrinsic reward, such as purpose & autonomy should be used instead and provide more long term results. It's much more difficult to put it in practice than simple extrinsic reward systems, but it pays.

Many experts did research on the subject. Here are my two favorites:

Daniel Pink made a great presentation at TED on the subject that is easy to watch and understand.

Alfie Kohn, author of Punished by Rewards, wrote on the subject:

Sure, bribes and threats can produce temporary compliance. Offer a reward to adults for going to the gym, or to children for picking up a book, and it may work -- for a while. But they come to think of themselves as extrinsically motivated, so when the reward is no longer available there's no reason to continue. Indeed, they may wind up less interested in exercising or reading than they were before.

Another problem with rewards (and punishments) is that it will modify how people behave. For example if you give bonus to your employee, they will be focused on obtaining those bonuses, regardless the other (company wide) objectives. It will creates individualism and competition between departments and employees. Resentment will take place and everybody will watch everybody. Especially when one of your aim is to "help measure individual performance".

The rest of the employee may disprove the rules of the game and quit. Increased turnover will then become a new problem.

Please note that many suggestions on how to improve motivation have been made in this community.

Answer 2

Yes, it could

But only if you design it very carefully, otherwise it might backfire. I've make some comments but thought I'd summarize my position

For reputation the main objective should be to provide a measurement that employees can use to track their skill improvement over time. Design it very carefully with that in mind, the hard thing is coming up with good ways to measure skill, I can't from the top of my head do that.

Badges is mainly a "fun" thing, I'd keep them mainly away and away from more skill-oriented issues. Ie badges like "this weeks night owl" or a group "Shipped! badge" would be ok. If you have some skillbased badges like "Fixed most bugs" or "Reported most bugs" think very carefully on how that might be perceived and gamed. Badges should be more about highlighting behavior than promoting it IMO. Be sure to have both team and individual badges.

I'd strongly recommend against negative badges, these things should be fun and making people afraid of making mistakes is dangerous. Generate a friendly helpful email for those cases instead.

I'd strongly recommend against letting them decide and vote on badges. People can send in their suggestions for badges but since their effect on people can be pretty severe what badges are used should be made by careful decision of a person who knows what they're doing and not majority vote.

Code reviews is an interesting idea and I guess one of the ways you could generate a skill value. Highlighting code and discussing it could be really helpful. However, it might backfire, if everyone knows they're being judge on potentially everything they write development may slow to a crawl. Especially with iterative development where you sometimes write something quickly and then refactor you don't want that behavior.

Perhaps that could be offset by either the person submitting code themselves or someone else only being able to submit code of a certain age. Nevertheless it can be tricky knowing what effects there'll be

I the end I think you'll have to try it and see what works and what doesn't, there's good book called Reality is broken that might be interesting. Also Daniel Pinks book "Drive" is a must-read.

Answer 3

In my opinion, NO, as it measures not the good practice itself, but a symptom (if others think it good practice).

To paraphrase a book by Uncle Bob (forgot the title): Good code seems almost effortless, it makes the problem look trivial, as if the language was made for writing it.

In my expericence, such code goes unnoted, and only after a long time it comes to attention, that this code never made problems, and maybe then one remembers, that the problem was, before the introduction of the code, a huge mess of uncertainty and vagueness. The code that gets praises in reviews is typically the one that the reviewers look upon on a good day when not in the mood to nitpick, and that has the fewest changes.

Answer 4

The idea would bring a new dynamic to the team. If you feel the team is in a rut then this is a good way to shake things up.

Just remember that it will not be all unicorns and rainbows. Some are not going to like the initiative so overall productivity/quality may suffer. However this risk may be worth it. Depends on your situation.

Answer 5

I suggest using extrinsic motivation (what you're proposing is a form of extrinsic motivation) to motivate people to do things that are "mechanical", repetitive and boring, such as:

• Showing up on time to meetings
• Getting timesheets submitted on time
• Updating documentation
• Sharing information with the team

I wouldn't use it for motivation on any type of work that requires creativity, or where quality can't be measured objectively. For instance, if you have a person making widgets and you can mechanically validate whether a part is good or bad, and you have a process that won't allow a part to be made unless it follows the approved process, then it's productive to motivate the worker with extrinsic rewards for productivity because the process won't allow them to take shortcuts to make more units at the expense of quality.

If you don't have those safeguards in place, then your attempt at extrinsic motivation will surely backfire. Programming falls squarely in this category - we just can't reliably measure software quality. That's because when you make a widget, it leaves the factory and doesn't affect the work you do on the next widget, but when you make software, you have to keep reworking it over and over. Stuff you do now has long term effects. It's these longer term effects that are very important but can't be measured. Intrinsic motivation is a much more useful motivator for this kind of thing.

That means:

• Let people take responsibility for their work
• Encourage people to talk to each other about what works well, and what doesn't
• Show genuine appreciation for peoples' work

Answer 6

Part of what makes this work is the large number of participants who do not know each other or have to work with each other daily. I would think that in a small group, it would become more a way to game the system to look good or to make your competition for promotion look bad. This is why formal peer evaluations are often a poor system. In a small group the people with the best rep will be those who are the most politically astute not the best programmers.

Answer 7

The short answer is, yes, it could work.

The slightly longer answer is, yes, it could work, but it could also backfire.

In addition to being a professional programmer, I'm also an amateur behavior analyst.

One of the signature findings of modern behavioral science is that behavior is strongly influenced by its consequences.

If you control the consequences, you can influence behavior to some degree. The degree depends on how important specific consequences are to each individual whose behavior you're trying to change, and on how easy it is for them to avoid your consequences and find others that they're willing to work for.

As a professional programmer, one consequence of writing code is that I get paid; stop paying me, and I'd stop showing up before long. Pay is a really important consequence to me (I'm raising a family), and there aren't any other consequences at my present company that I'd be willing to work for instead of being paid.

If you were my boss, you'd get to decide what consequences (incentives, reinforcers) to offer me. But you don't get to decide how I perceive them. For example, my boss might decide to offer a special parking space if I'm selected as "Coder of the Month". If I lived in San Francisco or New York City and I drove a car, I might be willing to work for that. But where I live now, parking isn't a problem, and I can walk to work anyway.

In my experience, the biggest risk you run with implementing a program like SO in the workplace is that you might be perceived as offering peer votes in lieu of paying people what they're worth.