

Ask HN Game mechanics (badges) for bug tracking = good idea? - petervandijck
http://playnice.ly/tour/#gameon

======
wccrawford
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.

~~~
petervandijck
The whole point is that the games improve your work. Why would that be a bad
thing? Why would motivation for your work be bad? Why would encouraging
submitting bugs be bad? Why do incentive programs encourage the wrong behavior
simply by their existence? (Trying to understand your argument)

~~~
lincolnq
The incentives never line up perfectly.

------
teamonkey
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.

~~~
petervandijck
In terms of game mechanics, badges != leaderboards.

Your system might have worked better without the leaderboard, but with the
badges?

~~~
teamonkey
Perhaps, but I suspect the main issue would remain: the same people would
always have the same badges, just because that's how they worked or that's
what their job entailed.

~~~
petervandijck
Think about stackoverflow badges. It's more about getting individual users
engaged, less about comparing users with each other. It's about making filing
bugs more fun, which should result in more testing being done by more people.

This link explains this better:
[http://developer.yahoo.com/ypatterns/social/people/reputatio...](http://developer.yahoo.com/ypatterns/social/people/reputation/achievements.html)

It's not about comparing yourself against others.

------
imperialWicket
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.

------
Construct
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.

------
znt
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.

~~~
petervandijck
But testing for bugs surely is pretty mundane?

~~~
znt
Yes it's pretty mundane and that's why testers are for. I really don't think
developers should spend much time on testing.

------
AntiRush
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.

------
jdp23
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.

------
ryanelkins
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>).

------
scrrr
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. :)

~~~
JonnieCache
I definitely think it would work a lot better for sysadmins, you're on to
something here. The day to day tasks of sysadmins fit more easily into xbox-
style "achievements," eg. automating/versioning various aspects of system
configuration, uptime records, both system wide and per service. The list goes
on.

Tell you what would be good, if your config management framework automatically
tracked these things for you. Some sort of international Chef leaderboard :)

------
gfodor
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.

------
petervandijck
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.

------
gyardley
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.

------
chopsueyar
Any good game mechanics links?

~~~
petervandijck
There are lots of them. This one is pretty relevant:
[http://developer.yahoo.com/ypatterns/social/people/reputatio...](http://developer.yahoo.com/ypatterns/social/people/reputation/)

Amy Jo Kim is also a classic: <http://www.youtube.com/watch?v=ihUt-163gZI>

Making work into a game: <http://www.adavies.org/blog/2010/03/15/gaming-the-
crowd/>

Note that almost all of these warn against leaderboards.

~~~
chopsueyar
Thanks for the links, especially Amy Jo. I read her book, "Community Building
on the Web", and it is an excellent read (still relevant - written in 2000).

