Alistair Cockburn maintains that software development is a cooperative game:

If software development was really a science, you could apply the scientific method to it. If it was really engineering, then you could apply known engineering techniques. If software development was a matter of producing models, then you could spend your money developing models.

However, it is none of those. Software development is a "game", a game of speed and cooperation within your team, in competition against other teams. It is a game against time, and a game for mind-share. You should spend your money to win that game.

Viewing software development as a game gives you better ideas on where to spend your money, how to structure your teams, and how they should allocate their efforts.

It's a fascinating, thought-provoking article on the essential nature of software development. I can now see why Bill de hra calls Cockburn "the agile world's best kept secret." I've only quoted the conclusion; I urge you read the complete article to get a full explanation of Cockburn's rationale behind the game analogy.

This game model of software development has stood me in good stead recently, as I evaluate military software projects and open-source software development. In some of the military software projects, what we see is predominance of the career and corporate-enhancing infinite games. It is quite clear that delivery of the software is a secondary concern, and growing the company, growing personal influence, or growing the career is what is many people's minds. The logic of the funny contractor behavior doesn't make sense until you realize they are playing a different game, in which different moves are called for. Then it suddenly all makes sense - even if you don't like it.

Open-source development is different because it is not a resource-limited game, nor is it finite and end-point directed. Linus Torvald did not say, "We'll make a shippable copy of Linux, and then we can all go home." No, Linus is around, and it will evolve. The game is interesting as long as it is interesting. Any number of players may show up, and they are not on a time-line. The game will abandoned as soon as it stops being interesting for the players. In that sense, it is much more like musicians playing together, or carpet-wrestling, or lego building. It is a cooperative game that is not directed toward "reaching the goal", and is not built around managing scant resources. And so the moves that make sense in open-source development naturally don't make the same sense for a standard resource-limited, goal-seeking software development project.

The idea that games can inform real world design problems is not a new one; Damion Schubert's presentation What Vegas Can Teach MMO Designers is full of similar insight. Casinos are the original MMORPG spaces, as outlined in Damion's presentation (ppt).

The concept of software development as a collaborative game appeals to me. It speaks to a deeper level of engagement in the process than "I get paid to do this." We play games because we derive some kind of essential satisfaction from playing them. You might even say it's fun-- either the explicit kind, or the implicit kind.

Fun may be more relevant than you think to your project. Raph Koster is a notable game designer and programmer who writes entire books on the theory of fun.

Take a minute to read Raph's classic theory of fun (pdf) presentation. What you'll eventually realize is that designing for fun isn't just important for game developers. It's important for all software developers.

Do users want to use your application, or are they forced to use it?

In a recent ETech07 presentation (also available as a PDF), Raph connects the dots more explicitly. He deconstructs amazon.com, ebay.com, and linkedin.com for what they really are: massively distributed games. You'll want to read the transcript of the talk along with the sides to dig a little deeper into the concepts:

As you accomplish more, there need to be variant challenges. Connecting to a CEO on LinkedIn vs. connecting to the pr dude = different. What you want is for the game to acknowledge the fact that it's tougher to get on Reed Hoffman's linkedin rather than someone who sells ads.

Social media is about cooperation, but the core of games is competitive. As soon as you give people a ladder to climb, they'll climb it. Ratings. Metrics of contribution. Other people need to see it to measure against it.

Software development is a collaborative game that you play, willingly or not, with your team and your users. You might say the secret of the game, then, is learning how to play the game so that everyone is having fun.