Finite and infinite games for software teams

Oct 12, 2015

In his book of the same title, James P. Carse describes “Finite and Infinite Games”1. A finite game has known and fixed rules, participants, objectives and duration. It’s possible for some of these variables to change - a chess match can last a variable length of time, for instance - but not without limit. Crucially, finite games end, and they normally end with an individual or team as a winner. We enjoy playing these games because they enforce enough simplicity that we can just about fully comprehend what’s going on. We can’t predict the outcome every time, but we can predict some of the patterns of play we’re likely to see and make sense of the ones that we do.

Infinite games also have rules, but there is no limit on the number of players or the duration of the game. If the rules begin to undermine the continuation of the game, they can - must - be changed to enable further play. The only fixed directive that an infinite game player should follow is to continue the game, and help others to do so. Playing an infinite game requires no particular justification beyond play itself.

To be clear, “game” in this context does not refer simply to board games, sports or video games, but to something closer to the meaning found in game theory - we can see pretty much any human activity as a game of some kind, if it can be described as possessing the characteristics described above.

Carse writes as a philosopher-theologian, and his view of finite games is somewhat negative. His concern is that a life lived from one finite game to the next - academic achievement, career advancement, one-upmanship and petty rivalry, conspicuous consumption, competitive parenting - would be hollow and unsatisfying, not to mention socially destructive. Finite games encourage a narrowness of focus that can limit creativity and encourage a self-centred view of the world. We can all easily imagine the person who is so concerned with meeting their next target that they forsake friends, family, art, wonder and learning while pursuing victory, only to begin the cycle again immediately at the conclusion of their current game.

Nevertheless, finite games are compelling. They make the world temporarily easier to understand by creating fixed rules and procedures2. They set targets and objectives, and establish criteria for measuring performance. They tell us what we need to do to win. Many aspects of modern life simply wouldn’t work at all without these structured games, and many games are popular not just because they’re enjoyable but because they enrich us in some way. Building a house or writing a book is a finite game that also leaves you with a house or a book at the end of it. Carse’s argument is that there’s nothing wrong with finite games per se, so long as we remain aware of the fact that we’re entering into a game, that we consent to playing, that we can exit the game when we want and that we are not consumed with winning for the sake of it. His book gives us the tools we need to see the games around us and to understand when we’re being sucked into games that we would rather not play, and how to structure finite games so that they work in our best interests.

An ideal life would therefore be one which combines energetic and engaged finite game-playing when appropriate, but also periods of reflection and undirected ‘infinite’ play. Finite games can be played for enjoyment or enrichment, but never as ends in themselves. The infinite game invites us to make new connections and find new ways to play, taking as much pleasure in helping others to participate as in the excellence of one’s own performance. As a philosophy, it’s one that I find useful and compelling.

In relation to creating software

One of the most dangerous words in software development is “project”. All kinds of things are called “projects”. Sometimes these have clear objectives, sometimes not. Sometimes the participants are known, sometimes not. The duration of projects is famously hard to predict, despite strenuous efforts to do so. You may see where I am going here: many software projects are poorly-constructed finite games.

It’s often hard to work out why everyone is playing, or what they’re playing for, and this leads to bizarre sub-games played with entirely different rules: competing over bug ticket statistics, disputing pet technology choices, targeting deadlines or feature counts rather than any true usefulness. Before long, the competition shifts towards deciding who is going to move on to the new project, where the whole thing can start all over again. Lacking clear direction, these projects-as-bad-games can only be brought to an end by cancellation or launch-at-all-costs, an unsatisfactory process involving long hours and sleep-deprived compromises.

Badly constructed finite games easily become ends in themselves. We end up playing to win the game, but we’re no longer sure why winning the game is a good idea. Does anyone actually want this feature I’m working on? Is changing this behaviour worth the cost if it means adding complexity elsewhere else? All kinds of trade-offs become extremely difficult to resolve if we don’t know what our primary objectives are, like football players unsure if they’re meant to be hitting the goal or the corner flag. When nothing makes sense, the only thing left is a kind of bare survival, the right to tell future employers that you were the Senior Solutions Architect on the BigCorp Replatforming Project 2013-2015 and still have at least some of your hair3.

This also turns out to be a really bad way to build network-connected services, which is what most software projects are meant to be doing. The steady march of technology means that it’s absurd to think of a public-facing technology product as being “finished”. The process of constant improvement and iteration, when seen from the multi-year perspective of an organisation rather than a project, looks a lot more like an infinite game than a finite one. The infinite game’s sole objective - to keep playing and to change the rules to enable this - maps pretty neatly on to the idea that products should be developed in order to find out what works, and changed if they’re not giving customers what they want. A finite game approach can tell us that we delivered on time, that we “won” the game, but tells us nothing much about the long-term prospects of the thing we have built.

If an ideal life is one of energetic finite-game competition punctuated by infinite-game play and discovery, the ideal approach to building software is to set short-term achievable goals, go all-out to achieve them, and then reflect on what has been learned from both the process of building and the effects of your product on the world. Then experiment, play, innovate and iterate until you are ready to commit to another finite game of delivery.

These different modes mean that sometimes we’re working to a clear goal, with well-understood metrics telling us when we’ve achieved it, reasonably static roles for the people on the team and for the stakeholders, and some fixed period of time in which to try to reach the goal; other times we’re experimenting without specific goals, but the products of our experimentation are going to give us much better ideas for our finite-game goals, and much better ways of achieving them.

In many ways, this is all common knowledge within the software industry. The importance of experimentation is well-known, and the superiority of clear goals and metrics over vague and amorphous deliverables is also well-known. It’s just a truth that seems to be unevenly distributed, with some highly productive firms that understand it clearly, and a rather larger number of firms that might copy the outward appearance of the better players without understanding how they do it. The next time you think about starting a project, think about whether it’s a game you want to start playing.

  1. The bug itself is explained here. The errors made by the developers are somewhat embarassing, strongly indicative of a failure to grasp how callbacks operate. This is not particularly advanced knowledge, and the notion that anyone could have attracted over $100m in deposits to an entity governed by code somewhere below the level of average JavaScript is… well, it’s something, that’s for sure.
  2. There is a significant echo of Carse’s work in David Graeber’s “The Utopia of Rules”; in particular, his explanation of why we like rules is very good.
  3. Not due to stress, just due to being set on fire frequently.