When you build an application or utility you are shaping a challenge for all the developers who ever interact with this code. For the rest of your team, for the future developers who maintain and extend the codebase, and for yourself – today, tomorrow, two years from now when you have no recollection of the code.

The challenge is akin to playing a game – and many of the rules of good game design apply just as well to your code base as the product of your compiled application.

A golden rule: ‘Guess what I’m thinking’ is not a fun game

But it is! I can hear some of you shouting. What about 20 Questions! What about ISpy! Yes, ok, they can be fun, given certain conditions: ISpy requires a small enough possibility space. It’s more fun in a car than a supermarket. 20 Questions (a beautiful binary search of the whole universe!) relies upon having an agent that can accurately tell you which pile of hay your needle resides in.

Without those constraints, ‘Guess what I’m thinking’ is just frustrating.

Let’s try it:

Guess what I’m thinking of right now. I’ll give you a clue, it’s an actual concrete thing.

No, it’s not that.

No, it’s not that either.

A comparison search of the whole probability space of ‘things’ is going to take a pretty long time.

This is, in itself, the main reason why I have never shifted myself over the pain barrier to learn Flex. There are just too many moments in which I find myself being asked to guess what Adobe were thinking, without the mechanism to make that game much fun at all.

Instead I’ve chosen to play other games: learning ruby, python, particular domains of problem solving and so on. Games in which I regularly get to intuit an answer that I’ve never been explicitly told in order to solve the puzzle in front of me.

Intuiting new solutions is fun (and the opposite of guessing)

Game designers work hard on providing the minimum amount of information, just-in-time, for the player to progress in a game.

If you take something as simple as a Facebook ‘blitz’ time-waster game, there are often layers of complexity which are invisible to the novice player, yet the player who is unaware of the hidden complexities isn’t penalised for their incomplete understanding.

As the player builds their experience, they eventually get sufficient exposure to the game’s patterns that usually they can intuit the additional layers without being spoon fed them. We may build in ‘hints and tips’, but for the majority of players these are timed so that they confirm what the player had already intuited for themselves.

If we’re simply handed an answer that makes sense, or it is presented in a way that reveals a hole in our thinking, it can sometimes be satisfying, but usually the chemical impact of ‘given’ information is minimal. So we don’t retain it. So we end up having to look it up all over again next time. We also only understand it as a specific solution to a specific problem, making it more difficult to teach someone else, who might have questions that expose the shallowness of our understanding.

Robotlegs makes your codebase into a great game

I experimented with Robotlegs and found that it brought fun to my codebase, and many other developers make the same claim. Of course it’s not perfect, but once I’d grasped a few key principles it felt as if I could intuit new solutions, and they often turned out to be correct.

Robotlegs felt like the original Tombraider games. I got a kick out of solving new puzzles for myself. I quickly felt confident taking on ‘boss’ problems, and it didn’t feel like I was just mashing buttons until I happened upon the right combination.

Other frameworks and utilities have often felt more like the early Harry Potter games – you do a lot of wandering around and from time to time you have to resort to a cheat site to get any further because the solution to the puzzle is so unintuitive. Not fun.

If our codebase is a game, how else can we maximise the fun?

There are two major pieces of work on the question “What *is* fun?” that I’m aware of – Pierre Garneau’s 14 Forms of Fun, and Marc Le Blanc’s 8 Kinds of Fun.

I prefer Marc Le Blanc’s model, partly just because the list feels more applicable to a wide range of problems. I’ve worked with consultants on applying this list to job design – profiling people’s ‘fun preferences’ against roles, and it maps well to teaching and writing as well.

The 8 Kinds of Fun

• Sensation – Game as sense-pleasure
• Fantasy – Game as make-believe
• Narrative – Game as unfolding story
• Challenge – Game as obstacle course
• Fellowship – Game as social framework
• Discovery – Game as uncharted territory
• Expression – Game as soap box
• Submission – Game as mindless pastime

If we substitute the word Code for the word Game, I see that Code as mindless pastime is a little tangential – though I don’t doubt that there are times when we want to bury ourselves in code so as to escape the world around us. I think the Fantasy and Discovery elements largely collapse into one concept for coders – exploring new territory / possibilities, often without a specific goal in mind.

My 7 Kinds of Code Fun

• Sensation – Code as sense-pleasure
• Discovery – Code as experimentation
• Narrative – Code as unfolding story
• Challenge – Code as obstacle course
• Fellowship – Code as collaboration
• Expression – Code as soap box
• Submission – Code as distraction from the world

Sensation – Code as sense-pleasure

Aesthetically, nicely laid out, clean code can be beautiful. It’s worth knowing that in brain-chemistry terms, “Truth” and “Beauty” are largely the same. The most attractive solutions combine both, something that mathematicians have always known intuitively.

Discovery – Code as experimentation

Whether your terrain of choice is generative art, byte weaving or just the kind of ‘what if?’ that lead Robert Penner to come up with AS3 Signals, there is something immensely satisfying about experimenting.

One of the reasons I advocate TDD is that a really comprehensive test suite allows coders (including you) to ‘play’ in your production codebase safely.

Narrative – Code as unfolding story

The reason I trained as an engineer and not a pure scientist or mathematician is that I get a kick out of making *things* that enter the world as physical or virtual objects, and change people’s lives in small ways.

I don’t think it’s a coincidence that at try { harder } the group featured people who’d had prior careers as choreographers and in theatre. Many developers are in love with the process of bringing a story to life.

Agile processes with great test coverage allow us to add new ‘episodes’ to the narrative of our product regularly.

Challenge – Code as obstacle course

This is the area programmers are most likely to be drawn to and aware of. Fixing bugs and delivering features feeds our ego and our families, and also keeps us from eating, sleeping and spending time with the people we love!

We want any obstacles designed in to our codebase to be the kind that can be overcome using the tools and patterns that novice users of the code can quickly pick up. And we want to avoid priming the player (developer) with red-herring solutions.

Fellowship – Code as collaboration

We can ‘collaborate’ with other programmers in real time using pair or group programming, or in near-real-time, passing iterations back and forth between us. Probably just as frequently, we wind up ‘co-creating’ work without ever having an interaction with the coder who comes before or after us.

Sometimes picking up someone else’s code is just a joy, and other times it’s a nightmare. My belief is that avoiding “Guess what I’m thinking” games in our codebase is the primary difference between the two. And no, comments, and even documentation, don’t get around this, because if there isn’t a coherent pattern that the game player can use to intuit novel solutions then it’s still no fun to have to reference the “cheats” constantly in order to make progress.

Expression – Code as soap box

Our code expresses what we believe about code. Have you ever met a developer who wasn’t passionate about their particular coding style?

Submission – Code as distraction from the world

Euro crisis? Shh… I’ve nearly got this code figured out…

About the Author

I'm an actionscript programmer living and working in a tiny village in the Yorkshire Dales, UK. I used to be a TV reporter, but my inner (and often outer) geek won. I also write stuff. Most recently Head First 2D Geometry.

Visit Stray's Website Visit Stray on Twitter