Ask HN Game mechanics (badges) for bug tracking = good idea?

To be honest, I don't think it's a good idea. Someone did this with git, and I ended up choosing not to do it because I didn't want games to interfere with my work. The people who like achievements/badges/trophies are the type who will actively work towards earning them, when they should be focusing on their work instead.

This is also the reason a lot of incentive programs are flawed... They encourage the wrong behaviors, simply by their existence.

And yes, I'm one of those people who like achievements.

At one place I worked we didn't have badges but we did have a live leaderboard showing the top bug stats (top fixers of the day, people with the most bugs, etc.). It didn't take long before people found it meaningless. Why? Because it always showed the same people.

Some people had lots and lots of tiny bugs as the nature of their job. They were always the top fixers. Others always had two or three big tasks and they were never on the board.

Some people had a large number of tasks to see to but didn't get many more bugs over the whole length of the project. These people showed up on the board as continually having the most bugs until 3-4 days before the ship date, when they'd finally whittled their stack down to zero bugs.

This could work for small teams, where there is great mutual respect, and a cultivated atmosphere of learning and collaboration.

However, in my experience, both for software development and quality assurance (which shouldn't be separated, but generally are...), this state is not generally the case. As such, metrics tracking and acknowledgement always seem like a good idea - but never are. Inevitably productivity will seem to skyrocket for the early trial period of awards (or any metrics-based system), until the ass-kissers and numbers-experts figure out how to game the system. Then you have people over-documenting bugs, using multiple VCS commits to "fix" minor text updates (because "they occur in different areas of the code", or something equally ridiculous), and similarly wasting time and efforts just to unlock an achievement. Once this starts occurring, the same people always carry the same prize (badge, whatever), and work ethic and motivation reverts to a state that is probably less satisfying for the team than it was prior to the achievement-based system. Also, your code maintenance and issue trackers are riddled with pointless records, making troubleshooting, reporting (other than for your achievements), and code reverts require a painstaking effort.

If you have a team that collaborates well enough to keep something like this from having detrimental effects - don't waste your time. Your team is already more productive than most.

People are extraordinarily good at learning how to game incentive systems. Even more so when the incentive system is simplified (badges, points, etc.) and the underlying problem is complex (fixing bugs).

The risk you run with any game mechanics system is rewarding those who game the system more than those who dig into the deeper problems. It would be easy to lose motivation to track down a segfault when another guy earned 20 'points' for fixing 20 sufferer typos, for example.

The only way to compensate for this is to have someone actively and intensely assign priorities and estimated difficulties for each bug. Getting this right could take some time and effort, and you still run the risk of undervaluing the little bugs, etc.

I think a better system would be 'now that...' rewards instead of 'if then' rewards. Recognizing someone for their contributions after the fact has been shown to be more motivating in the long term than incentives laid out ahead of time. Public, non-systematic recognition for a job well done goes a long way.

I think achievements are useful for making people repeat mundane tasks. Developing software is not a mundane task as you tackle with new problems most of the time. Maybe you can change the app's functionality so that the developer earns medals for every unit test his code passes.

It seems that this could easily introduce unproductive behavior. "I want this badge so I'll introduce this bug and then fix it." Or "you introduce this bug so I can fix it".

For an open source project, sure, why not. It might make things more fun for developers or, more importantly, bug reporters. The supposed loss in productivity isn't an issue here as people are volunteering their time.

When I was at Microsoft, the Windows team introduced some game mechanics to get internal developers more involved in filing bugs during the pre-beta dogfooding stage. I can't remember exactly how it worked -- something about getting a letter each week if you filed a couple bugs (with review to avoid dups etc.) The folks running the program told me they couldn't believe how successful it was; people's desire to show they were helping combined with natural competitiveness to get great results, and the quality of the bugs filed this way was just as high as others.

That said, all the points others are making about the risk of encouraging the wrong behavior are very valid concerns. Get people on the team -- and outside eyes -- to review the scheme before going forward with it, and expect that you may need to tweak it once or twice.

The problem is that most feedback systems (which is mostly what gamification the way it's being implemented now really is) are measuring quantitative results. Bug tracking is a job that can be hard to quantify. All you can usually measure is quantity. There is virtually no quality metric involved. You have to make sure that the goal you're trying to accomplish by adding game mechanics doesn't get lost. Too often the game mechanics end up being there for their own sake.

As others have mentioned you also have to make sure to not create unintended negative consequences. For example, maybe people earn a badge for fixing 5 bugs in 20 minutes. What happens then if people stop committing bugs so they can "build up" fixes and turn them in at once? What if people start creating bugs for themselves to fix? You can very easily create more problems for yourself if every angle is not carefully thought out - and even then you'll probably still create some problems.

Keep in mind I say all of this not as a game mechanics cynic but as someone whose entire startup is based around helping other people incorporate game mechanics (http://iactionable.com).

Ha!

I think this is a good idea, but not for software developers. Most developers, the ones you want to work with anyway, enjoy programming and they also take pride in their work and thus will fix programming errors without any extra incentive. But it might be cool for other jobs, stuff that is less fun.

Like system-administration. /me ducks. :)

Am I the only one who thinks that "badges" showing up in all aspects of life is becoming quite insulting? I don't need the desire for a circular PNG image to motivate me to work hard or effectively.

And to answer that, I think it's an awesome idea. I can totally see the team getting more motivated (especially non-developers).

I've noticed people using badges (outside of any software) during testing. Things like "I'm the bug king!" etc. I see that all the time. So building that in to the software seems like an awesome idea.

It's a fine idea as long as it's a voluntary system adopted unanimously by an enthusiastic development team. If it's imposed from without on an existing team with existing culture and rituals, it'll likely be a disaster, with game manipulation leading directly to cynicism.

I'm on the outside looking in when it comes to talking about developers, but in my experience developer teams self-organize, coming up with their own mechanisms for positive and negative reinforcement over time. As long as that culture's working, outsiders shouldn't mess with it.

Since every culture is slightly different - one team has a build animal, another has complex rules for the buying of donuts, etc. - building a product that impacts team culture is challenging. Anything you build is going to have to be pretty customizable and flexible in order to attract a decent mass of users. For instance, in a badges-with-bug-tracking system, I'd expect the team to be able to determine which badges are used, define their own badges, upload artwork for their own badges, and perhaps have some voting mechanism around the rewarding of a badge. Even then, it's a tricky thing.

Any good game mechanics links?