Software Development as a Collaborative Game

blog
21

If we’re talking about something like Chutes and Ladders, or whatever crappy game Raph Koster’s working on now (he has made some of the least fun games I have ever played), then I think the analogy is crappy.

If we’re talking about games in the general sense of game theory, yes, definitely, but game theory is almost too broad to be relevant. It is a better way of defining the work of software development than engineering or science though (except that working as an engineer or scientist is probably better defined by game theory than science or engineering too).

22

Thanks for discussing this idea. I think some people still see the word ‘game’ as ‘amusing oneself’. ‘Game’ stopped meaning that over 50 years ago when the mathematicians got involved and started stretching its domain. Nowadays, as someone posted above (the Wikipedia definition) games involve making moves, using strategies, having outcomes … Wittgenstein kept pointing out that games involve people accepting conventions of behavior, and that the moment they stop operating within those conventions, they have stepped outside the game (stopped ‘playing’ it).

The paper referenced was given in 1999. I’ve had plenty of time to try other ways of getting to the same end thought. http://alistair.cockburn.us/index.php/Software_Development_as_a_Cooperative_Game_060 (http://tinyurl.com/22xdzy) is a talk in which the first several slides try to get to it from a different starting point.

The different starting point is the question: if we didn’t use a metaphor, and just looked at what software development consists of, what do we find? The answer is given in the first slides of that talk.

Then the second question becomes: how can we get back to that long statement of what software development is from a short statement? And the answer to that one is “cooperative game of invention and communication”, described at http://alistair.cockburn.us/index.php/Cooperative_game_manifesto_for_software_development (http://tinyurl.com/fjpl5).

All in all, I think of software development as an entry in the category of games called cooperative finite goal-directed games. Much of theatre, exploration, and sections of business fit into this large category of games.

More recently, as I fiddled around looking for /analogies/ to /compare/ software development, I constructed the “Swamp Game” as another entry in that category of games, which holds up very well as an analogical comparison partner for software development. The Swamp Game is described in the second edition of Agile Software Development, and also in the article (http://tinyurl.com/3x6s4r). Here’s the extract:

"To understand the shift of strategies that occurs when working with games series’, let us construct another resource-limited cooperative game and examine it. Consider a race across an uncharted swampland in which some particular (unknown) artifact must be produced at some particular (unknown) place in the swamp. A team in this race would employ scouts and specialists of various sorts, and would create maps, route markings, bridges and so on. They racers would not, however, construct commercial quality maps, roads or bridges, since doing so would waste precious resources. Instead, they would estimate how much or little of a path must be cleared for themselves, how strong to build the bridge, how fancy of markings to make, how simple a map, in order to reach their goal in the shortest time.

If the race is run as part of a series, there will be new teammates coming after them to pick up the artifact and move it to a new place. The first team will therefore be well served to make slightly better paths, maps and bridges, always keeping in mind that doing this work competes with completing the current stage of the race. They also will be well served if they leave some people who understand the territory to be part of the next team. Thus, the optimal strategies for a series of races are different than for a single race.

There is no closed-form formula for winning the game. There are only strategies that are more useful in particular situations. That realization alone may be the strongest return for using the economic-cooperative game language: people on live projects see that they must use their minds at all times to observe the characteristics of the changing situation, to collect known strategies, to invent new strategies on the fly; and that since a perfect outcome is not possible in an overconstrained situation, they much choose which outcome to prioritize at the expense of which others."

I know this was a long post. The idea of looking for a metaphor or analogy is so that we can get enough distance from our activity to look at its elements in ways we already have built up to look at things. The quality of the metaphor/analogy relates to how many patterns we find usefully match before the metaphor/analogy runs out of steam. So far, the game metaphor and the swamp game analogy are providing good value in that sense.

Alistair

1 Like
23

Other things people measure themselves by: What car they
drive (…)

Then design rule #1 is always the same: design for crazy, because
people don’t come in any other flavor.

You have to design to accommodate the way people actually work,
instead of the way you wish they would work.

Not necessarily. Do people expect reasonable pay for the work they put in? Sure. But my experience is that when you have to start pandering to the “my car is bigger than yours therefore I am better than you” aspect of people, then you are poisoning the work environment.

My experience is also that the only time you have to do this is when you have to force or otherwise coerce people into doing things they would not otherwise do. You have the “look I’m only doing this for the money” crowd. But living that kind of life - living in “bad faith”, as it was described in Harvard Business Journal, takes its toll. “Selling your soul to the devil” is an analogy.

The result is a general lack of enthusiasm - people aren’t enthusiastic about the project itself, but sees it as something unpleasant that should be dealt with as quickly as possible, so they can get the cash at the end of the project.

End result? Well, what is the success rate for IT projects?

So in summary - yes, you can design for how you say people actually work. Many do. The results will be as they tend to actually be: Poor. The fact that most people do what you do - design for the way you think people are, and that the results are uniformly poor, is not a coincidence.

I design for the way people damn well better work if we’re going to succeed. If they don’t, then they work somewhere else.

24

I design for the way people damn well better work if we’re going to
succeed. If they don’t, then they work somewhere else.

I should add to this that yes, finding good people is difficult. (But worth the effort.)

25

Hi Alistair, nice to hear from you.

‘Game’ stopped meaning that over 50 years ago when the
mathematicians got involved and started stretching its
domain.

Well, that’s one part of the problem. The big problem is that you’re not using game theory at all. First you start off talking about game theory and different type of games, but you stop short of building the game theoretic model of software development.

Therefore, your theory has zero predictive power. There’s no model to put facts in and get predictions out of. There is no game theory in there.

We can talk about rock climbing and swamp races, but that’s not what game theory is about. It is about defining moves and payoffs and probabilities so that one can plug in numbers and get predictions out of it.

Now, where you pretty much hit the truth dead center is here:

people on live projects see that they must use their minds at all
times to observe the characteristics of the changing situation, to
collect known strategies, to invent new strategies on the fly; and
that since a perfect outcome is not possible in an overconstrained
situation, they much choose which outcome to prioritize at the
expense of which others

Which reminds me of level 5 of the Dreyfus model of knowledge acquisition:

http://w3.msi.vxu.se/~per/CP-web/PBDDSKIL.HTM
"An expert generally knows what to do based on mature and practiced understanding."

My suggestion: Tell everyone to get their asses to level 5 and be done with it. It takes a while, but there are no king’s roads to project management. Forget about analogies with swamp races, rock climbing and game theory. That’s just a waste of time and money.

26

tcliu writes : “The big problem is that you’re not using game theory at all. First you start off talking about game theory and different type of games, but you stop short of building the game theoretic model of software development.”

Well, actually I /don’t/ start talking about “game theory”, so the rest of your post doesn’t follow. I don’t particularly ever intend to talk about “game-theoretic model”, because I consider human actions in these situations too open-ended to apply formulae and numbers to. I could be wrong on this count, and that wouldn’t hurt my feelilngs at all — I just won’t go there personally.

Not having a game-theoretic model doesn’t mean there is nothing to learn form understanding that software development can be seen to operate in a similar space as an expedition to the south pole, or an n-pitch rock climb, or putting on a theater piece, or putting out a newspaper. On the contrary, I have seen project managers’ and executives’ eyes open quite a bit when they reconsider their software development project as a series of moves and strategies in a rather open-ended game.

There are similar logical problems with your recommendation “Tell everone to get their asses to level 5 and be done with it,” but I’ll let other contributors point those out to you if you don’t already see them.

Alistair

28

The key points to grasp here are that the success of a project depends on how people communicate and cooperate and that software development models should be used as guides to create flexible processes for teams of individuals.

My Father used to describe management as “managing people”. The “Tell everone to get their asses to level 5 and be done with it,” model is rigid and unforgiving and will lead to poor morale. You may as well carry around a whip. My Father also liked to say that “people are often promoted to their highest level of incompetency.” It takes maturity and a great deal of experience with people to manage successfully. Respecting unique differences while managing resources is a talent, not a skill.