I didn't read the article but I am going to read your thesis. I have a question: Is it possible to have enterprise gamification? What should be the end goals - the achievements so to speak?
Isn't the whole idea of gamification(an idealization that didn't quite happen I guess) is to make crud work seem like fun? But, then, wouldn't repetition of the same joyless task be mundane to the point of being Sisyphean? I agree that a game achievement is fun to get but archiving mail day after day would get old pretty fast(I think).
And as a grad student myself I must ask, have you considered the possibility of gamification systems in academe(school in general)? I guess that's what the trophies(and convocations) are for, right?
So there is evidence that people will go looking for intrinsic motivation. The famous example is that of a car builder as described in relation to Flow Theory [1], where this guy on an assembly line would try and make a game out of his small piece, trying to assemble it faster and faster. However, what happens when you introduce extrinsic motivators into the mix is what is known as the Overjustification Effect, where people start to think they are doing it for the extrinsic motivator and erode their intrinsic motivation. If we gave our car mechanic an extra $20 if he was always in the Top 20% of workers, he's going to start thinking he's doing it for the $20 and not because he wants to do better at his internal game.
So if we assume that people will go looking for intrinsic motivation in even the most tedious jobs, then we can design structures that provide feedback to enhance that motivation. The key to metrics is that they need to provide feedback on the things that the employee cares about and helps them to understand how they are doing in whatever motivates them. For our car mechanic, maybe we want to do things like:
* Show a timer with how long it's taking him to make them, how he's doing over the day, how he's doing in comparison to yesterday
* Show him the cumulative effort, illustrating how many widgets he's put together
* Show him how his work is important to the company (providing him with purpose), maybe with how many cars he's allowed to be built, and which dealerships they go to
None of this is really "gamification" as you'd think of the term. They're means to support the gameful context that the employee can choose to, or not choose to engage in (e.g. the stock market is basically gambling, you choose whether you treat it as a game or not). It is, however, going to help get the sort of output that you wanted when you went looking for gamification.
Notice the risk here: If he's building things faster to play his game, his work might get sloppier. That's why such things need really careful monitoring and tweaking before being deployed. Same thing with the Target checkout thing where it shows how quickly the checkout person is pushing people out the door. My guess Target's real goal isn't getting people out the door, but getting happy customers out the door. If a checkout person is being incentivized to actively not help out customers with problems that require more attention, then it's possible it's working to harm the overall goal.
EDIT: As far as gamifying education, you might be interested in "Punished by Rewards", which is a book about intrinsic motivation in schools, and was published long before gamification appeared on the scene. The book has it's critics, but it's an interesting take.
Even further than just the Overjustification Effect, it is important to point out that as soon as you introduce the concept of work-as-game, you turn work into a competition, where you are specifying a successful outcome. Then the players(employees) have to choose rational strategies to "win".
A major problem in enterprise gamification efforts is when the rules, strategies, and outcomes conflict with the ultimate business objectives in the first place. Others here are correct to cite examples where optimal strategy to win a game differs from the goal of the company. e.g. to rank customer service agents based on customer calls handled, not the outcome of the calls.
Ultimately, additional complexity added to almost any job will backfire in some way. Creating a situation where employees need to both do the job and win the game is problematic, made worse when you are already providing them with the compensation for them to do the job, and the game mechanics that favor winning the game.
There is a parallel here between Gamification of Work, and Enterprise Social Networks (Yammer, Chatter, etc.) where these collaboration suites have had trouble catching on, since they were additive to the existing process of email. It tends not to matter much that the UI/features are better for a wider array of collaborative tasks if they have to be used in addition to the pre-existing systems. Collaboration software competes with time spent collaborating by other means, gamification competes with time spent working toward other (more relevant goals).
I don't have research for you off the top of my head, but here's anecdotal support -- there's no way these people can get this good at their tedious menial jobs[1] without finding a strong (superlatively strongest in the world) intrinsic motivation to perform better.
As Lewisham puts it, structure to maximize enjoyment of their intrinsic games is the best. Ideally, find out directly from the employees (or by being them for a while) what intrinsic games they play for their tedious tasks, and then try to build structure around making it more fun -- there's essentially 4 parts to it - holistic goals, performance stats, realtime feedback (these 3 are mentioned by example by Lewisham), and the hardest-to-implement, fun interactions.
The last is complicated, but for example, it's the reason why a clickety mechanical keyboard may be more fun to type on than one of those polymer rollable keyboards, if you have an employee whose job is to type all day [you and me probably]. Sometimes workers find ways to turn their interactions with their work fun on their own (like those in [1]), but for the less intrinsically motivated, employers facilitating it can have a huge effect.
The key word is pipeline. If you have some analysis that runs in several stages, you'll be taking the output of one stage, and connecting it to the next. If you want to compose multiple phases, chained together, raw MapReduce isn't going to help you very much with the chaining.
What's described in the paper is a way to do the chaining in a nice way. The system will take care of writing the raw MapReduces for you. But it'll also do a lot of work on the interconnections between your stages as well.
MapReduce wasn't designed for iterative algorithms or streaming data, whereas Google Dataflow and Spark (http://spark.apache.org/) make iterative algoritms easy. It's a much simpler programming paradigm, and it allows you to do iterative graph-processing and machine-learning algos (http://spark.apache.org/mllib/) that are impractical on MapReduce.
> “The broader mindset here is not just code,” said Bill Gross, the well-known serial entrepreneur and founder of an incubator called Idealab. “We have engineers with taste.”
The only problem with Hy is that it's not, technically, a Lisp: it's Python with a Lisp syntax so that you can programmatically manipulate Python AST trees with a simple interface: plain-old-data-structures, iterators, and functions.
Lisp is more than just parenthesis, just as Python is more than just whitespace-delimited blocks of text.
We can do some neat tricks by transforming a parenthetical syntax to Python AST that may even seem like Lisp some of the time... but the semantics are and will always be Python without stretching truth and logic a little.
I am not trying to be obstructive or distract the discussion - but it occurs to me that anyone can shoot down the drone and retrieve valuable artifacts that are being transported.
I think the most important lesson is that traditional economists are just going to have to learn to live with the fact that their theories don't explain bitcoins.
or they might just be kicking themselves for not buying coins sooner. lol.
