Super-Star Programmer: The Game

Years ago I was a keen participant in a game design forum called The Forge where they'd made a taxonomy of player priorities: gamist, narrativist, and simulationist (GNS). Different game systems favour different priorities and are more or less satisfying to different players depending on their priorities. [1]

I think formal software development processes are games: you follow the rules to get the experience of being a software developer, a super-star programmer.

The game itself

We all have a notion of super-star programmers and we set up a whole lot of rules and rewards that guide us toward behaving like super-star programmers.

There are lots of things we think super-star programmers do: They make use of computers to prove things about their work. They know about the up coming tasks. They interact with interested parties throughout their work. They make it easy for others to find out what they're doing. They actively learn and share their knowledge. They seek out feedback and create opportunities to act on it. Their code works all the time. They stay on task and their work is relevant to requirements.

We prescribe various practices to get those outcomes in our work: various meetings (planning games, retrospectives, root cause analyses, stand ups); various reporting systems and information radiators; Kanban; process steps that require consulting with specific individuals or teams; TDD and pairing; Continuous Integration; and other practices that we consciously build in to our process. All these together are our game.

It doesn't always work: all these rules don't always produce the playing experience we hope for. And it works differently for different people. A given process may be effective at guiding some developers and be quite disheartening to other perfectly professional developers.

We'd like to be super-star programmers who just do all this stuff without the need for the explicit process. That said, game playing can be one of the best ways to learn hard things.

Lessons from game design

GNS gives us some clues about why processes sometimes go wrong and other times they go right.

The gamist priority: gratified by the rewards and adhering to the rules in order to get those rewards. On the one hand they will stick to the rules, often with lots of energy and enthusiasm for the system itself. On the other hand they are likely to exploit flaws in the system. If you create an environment were some important activities are outside of the rules, then they may ignore those activities. "Gaming the system", sums up the risks of relying on process with gamists.

The simulationist priority: these guys really want following the rules to deliver the goods, and they can adapt to quite intense and restrictive systems. They'll work with flaws in the system if they understand the objective. They'll make the effort to do it right rather than just doing a minimum to satisfy a rule. By contrast they can be quite annoyed if after abiding by the rules the results don't follow as promised. The most diligent players can be the harshest critics of the game and are easily frustrated by imperfect systems.

The narrativist priority: attentive to the arc of activity, the big picture and human concerns. At best they'll take the simplest framework and make it work. But they are notorious for abandoning the rules to make the game suit them. Rules that say what you're trying to achieve are important to them. Conversely insisting on a process without giving attention to the desired outcome will seem like manipulation and frustrate them in very short order.

(I always self identified as a narrativist with some simulationist leanings.)

How we play in our office

Looking around my office I see all of these priorities to varying degrees among my colleagues.

We have a step in our process to talk to QA. The simulationists are likely to actually take time to talk to QA when that step requires it, after all it's what we're supposed to do. But the system gets abused by the gamists who might take a few passing comments as justification to say they've satisfied that step. Meanwhile the narrativists get annoyed because they did talk to the right people but at some other time when it seemed to fit in better.

Thinking about when we've tried to introduce promising new practices. The gamists take to them with gusto, making them work to get new rewards from a new rule. The simulationists trudge through, annoyed that it seems we don't really know what will deliver the desired outcome. The narrativists grow frustrated at yet more things slowing them down.

How about stripping back or simplifying a system when it's going smoothly? How quickly do the gamists stop doing that good thing? The simulationists grumble about changing the rules when they were working just fine. While the narrativists feel liberated by being able to do it differently and perhaps even better out of the opportunity.

And so we suffer seemingly endless rounds of process tuning, never satisfying anyone.

It's not a game!

In the gaming world we could always say that if you don't like the game then don't play. The situation in the office is harder.

For all my love of games, playing this game is secondary. Yes, it helps me when I'm not up to super-star programmer standard, it helps keep us all on the same page. But what matters more is actually striving to be a better programmer, not just playing at the game.


[1] I've taken some liberties in my interpretation of GNS for sake of illustration, I don't intend to argue the fine points of GNS theory here.