Just Playing Games

I used to be very interested in game design, particularly the principles of reward systems. Basically a game mechanism is a system to reward (or penalise) behaviour and a game is about the behaviours it rewards.

Many games are unsatisfying or unsuccessful because they claim to be about one thing but reward something else. Dissonance between intent and practice is often very distracting. Sometimes players end up with a tacit social contract to not play by the rules but rather to improvise within the game's framework to get the experience and rewards they care about. Subverting a flawed game that way often requires being very motivated and having a firm vision for how things should be.

It seems to me that many of our practices and processes are like games. They aim to limit our behaviour or reward us for particular patterns of behaviour. But sometimes they are blunt instruments that can overly restrict behaviour and not reward the behaviour we really care about. A classic misguided reward is flagging that something has been done at the end of stage when what is really desired is to engage in some activity throughout the stage. For example we allow progress when we can flag that we've spoken to QA but that's just a proxy for involving QA throughout development.

And so we explain there are nuances and principles and that you're not doing it right if all you're trying to do is get past the check point. Imagine a game that says don't do what the rules say, instead improvise to do what the rules intend. At the end of the day the system has been set up to make the game about progress through stages, we reward progress through stages by making that progress visible, so indirectly we reward taking a minimum of time to get through the check points.

Similarly different types of computing work can deliver rewards in different ways. I've found build systems to be all or nothing affairs, indeed anything that involves searching for the right configuration tends to have no visible result until it is complete, a big payoff at the end of all the work. By contrast programming tends to deliver incremental progress from ongoing work, no grand climax but rewarding ongoing tinkering. These different patterns of reward for effort fit or conflict with different peoples motivations.

Being aware of what types of rewards drive different people is important in getting good work done rather than boring or frustrating them. Similarly being aware of the rewards implicit in any given task may make it a chore or treat to different people.

We should being aware that our explicit processes are fundamentally games: constraining behaviour and rewarding players. We need to be attentive to what behaviour is rewarded and how a developer might subvert the intent of the process by observing the game rules to the letter.

Perhaps we need to ask ourselves more deeply what is happening when good work gets done and aim to reward that directly, rather than playing games that need subverting by playing to lose but doing the job right.

We shouldn't assume that the games we've been playing are the best games to play.

Who is the process for?

One process to rule them all and in the darkness bind them.

I've been puzzling a lot about process recently. Why are we more interested in Process over People. We talk about processes, we tinker with and tune and polish processes, we treasure our precious processes, gollum, yes we do, my precious.

I've been asking the question of anyone who'll give me a minute, "why do we give more energy to process over people?"

My own answer is the most cynical: I find it hard to speak well of our clients and I'm indifferent toward our products - I give energy to my process to keep me working in a professional way even when I'm not motivated by my clients or product. Another answer is that processes are easier to change than people and programmers are almost by definition control freaks.

Processes are safety nets to ensure that good practices are given appropriate time and effort, knowing that we can't be trusted to always do the right thing.

So it makes sense that I should have a process that compensates for my weakness, but my weaknesses are not your weakness, so why do we imagine one process will suffice? Is that one process the set of all the things that we need to compensate for everyone's weaknesses, (assuming those things are not contradictory)? Or is the process just compensating for our common weaknesses, (perhaps giving us an excuse to not attend to our personal weakness, after all I'm following the process)?

Structured process should be a tool that you shape from a knowledge of your weakness and that serves to compensate for those weaknesses.

I value a team process. But I recognise that not everything in the process is there for my benefit, and some things I really need are not there. As a professional I aim to augment the team process with my own personal practices so that my work is better. As a professional I recognise that playing along with things that are not necessary for me can help others and improve the whole team's quality of work.

But how to strike the balance? How to keep the balance in the face of change?

Doing things the old way

We've been talking recently about why we get stuck in processes that no longer serve our needs even though they were the right thing when we started.

There were a few things that came up: tests written in particular ways, particular sign-offs in our development cycle, the idea that we must have certain types of tests, writing code in particular ways, and so forth.

There was a bit of defensiveness when unnecessary things were highlighted. We didn't set out to be inefficient, and we wanted to explain the context that made these things good ideas. Understanding that context and understanding where we're at now are both important for positive change. Lack of understanding just fuels defensiveness.

An experience of mine is a good metaphor:

Years ago I broke my left knee in a motor accident. I was very careful to do as I was told during my recovery and have since restored symmetrical strength and flexibility. (I even went on to do several years of regular fencing practice.)

Recently I've started Aikido classes and a basic training technique requires falling backward when thrown: lower yourself down with the rear leg and roll smoothly on your back, a very safe and effective way of falling. I can do this easily with my right leg but I always hesitate with left leg -- I hop back awkwardly or I fall and land heavily on my butt. I learned to defend my left leg after the accident, and I'm still unconsciously defending it long after the need has passed.

Now I've got pressure on me to change. I'm getting to the mats early and practising that backward roll slowly and gently so I know what it should feel like. I'm paying attention when it turns out right in class and trying to remember those successes more than the failures. I speak to other students and the instructor so that they give me the chance to practice it right. Eventually the right move will become unconscious. Who knows but maybe losing the habitual defence is the last stage of healing for that old injury?

Some of our quirky processes may be the same. At a time of need we carefully included steps which now are not needed. We've learned our lessons, but we've spent so long valuing them as necessary defences that it's hard to let them go. In fact, without some external perspective or change to bring them to our attention, we don't even notice that we're doing anything odd.

The puzzle is how to drive positive change. If my broken leg metaphor is right we need things like: a problem that highlights the cost of now unnecessary practices, recognition of why they were valuable and re-assessment of our current condition, recognition of our growth and trust that we won't backslide, and alternatives that we can practice that might also allow us to grow even further.

In the end an up to date set of development processes and techniques should make our day to day work more comfortable and effective, that's worth the effort.