I like this idea, but you strike at the heart when you said "willingly or not". The measure of a team is often defined by its weakest member. Therefore, if everyone is set on this game mentality except one, the game slows to the pace of that anomaly.

For a real example just think of requirements gathering. If there were another team across the room racing to gather requirements, wouldn't your team be moving a bit faster. However since there is not another team and the only opposition is time (which is often never fixed), requirements take a pace all their own. Meanwhile developers hungry to continue playing the game (eg. coding) are stuck waiting for info from the top.

How can you get _everyone_ to play?

I'd argue that the same sentiment can be applied to traditional engineering. The idea that there's some ideal method you can apply to design a perfect bridge is as much an academic fantasy as whatever they teach computer science students these days.

Defense software projects are always screwy because the DOD ties funding to some really absurd metrics, like lines-of-code-per-developer-per-hour (seriously, that's one of them). You can expect the end result to suck with a business model like that.

I've been saying it for years: You cannot, EVER, outgrow playing. You just express it differently. If you aren't having fun, you're doing everything wrong. Stop and reevaluate. Debug the code of your life, you've missing the goto [fun] statement.

Think about what you enjoy doing, even if it doesn't seem like "playing". Do you enjoy blogs? Do you enjoy TV? Something stimulates the "fun" zone of your brain. Even homicidal serial killers play. They just wind up killing people when they play.

Play time is fun. You cannot live without play time. You cannot live without fun. To deny it is to deny your own existence. Man was built to enjoy himself. We're just champions of denying ourselves.

Life can be divided into two categories: want to / have to. If you had your druthers, wouldn't you do the "want to" more than the "have to"? I know I would. And that's something important to remember: Do you "have" to do what you're doing, or do you "want" to do what you're doing?

Carry that into software development. Software is developed the way it is because you HAVE to develop it that way. You don't follow the paths, you wind up without software at the end. Or software that is a failure. But my opinion is this: do only the bare minimum you HAVE to do. The rest is WANT.

I mean, if we always did it the way we HAVE to, we'd never have developed anything new...

Whenever I see a "X is Y" philosophy, I cringe. It reminds me of the blind men and the elephant. X is X. Your associations and feelings about X may be Y, but that doesn't make X Y. K?

Software development as a whole is only a game if you stretch the meaning of "game" to incorporate software development. The problem is that you lose a lot in the process. Cockburn has definitely identified many similarities between software development and games. But he ignores the things that don't match. Specifically, the underlying meaning of the word "game". What if a co-worker came over to your desk and said: "I looked at your code. Do you think this project is a game?" What is the meaning of answering "yes" to that? What is being asked?

What software development is is captured perfectly well by the words "software development". It then happens to be an activity carried out by humans who will interact. You can call that part a game, but then you are really expressing your feelings about that particular aspect of software development by using the more precise word "game", much like "war is hell" isn't a statement of fact, but a statement of aversion to war.

Tortured analogy and oversimplification.

> As you accomplish more, there need to be variant challenges.
> Connecting to a CEO on LinkedIn vs. connecting to the pr
> dude = different.

I'm not even going to start describing what's wrong with viewing networking that way. If you do, then those links you have gathered are not a network. You may have a network-shaped mental illness, but not a network.

I like to think software development as a game, I allways did. Thinking that way makes my days at work a lot shorter, makes me even enjoy them. Even if it is a "tortured analogy and oversimplification".

Cheers!

Whether Cockburn is a true observer or not, acquiescing to the notion is to devolve into the morass described in a book from some years ago, named IIRC, "The Gamesman". It's about the perversity of Western Capitalism. Perverse in the sense that it rewards anti-intellectual activity, as if it were. Rewarding bad behaviour only leads to more bad behaviour. Sort of like voting for Bush and thinking you're smart (Ok, Ok, Ok).

Of course, if I'd taken a minute to do some research, rather than reacting, I would have gotten this background, and saved a post:

from an amazon review:

The "Gamesman" hero of the book is Richard Hackborn, who 25 years later recruited Carly Fiorina to run Hewlett-Packard.

It was published 1977.

> You may have a network-shaped mental illness

Really? So you don't think people measure themselves by pagerank, backlinks, technorati rank, alexa rank, page hits, linkedin contact counts, myspace friends, ebay feedback number, diggs, and so on?

http://www.codinghorror.com/blog/archives/000717.html

I agree with Koster: it's part of the human condition. If you put a ladder in front of people, some of them will feel compelled to climb it.

I think that Alistair's views have been inadvertenly misinterpreted in the comments above. He is using the word "game" in the broadest sense imaginable. Personally, I interpret his meaning to be something along the lines of "an activity which the participants choose to engage in".

Alistair's examples of games include chess and tennis (competive goal-directed games) storytelling and jazz (non-goal directed) and rock climbing and software development (co-operative and goal directed).

Importantly, he is NOT saying that software development is ALWAYS about having fun, pushing hidden agendas, or ego-tripping. (Although those things may be present as individuals persue their own ends, the big picture is about making some software. That's no different from people trying to show off, conceal their weaknesses, or attract members of the opposite sex while engaged in the "game" of rock climbing. The big picture is still about climbing some rocks.)

To "Tcilu", Alistair probably agrees with you that it's not a perfect analogy. His point is that it's a more useful and accurate analogy than saying "software development is X", for most _other_ values of X.

> Really? So you don't think people measure themselves by pagerank,
> backlinks, technorati rank, alexa rank, page hits, linkedin contact
> counts, myspace friends, ebay feedback number, diggs, and so on?

Other things people measure themselves by: What car they drive, what iPod they have and the size of their house.

I do think that all of that is done, and I stand by my assertion that if you measure yourself by any of them, you are crazy.

John Rusk:
> Alistair probably agrees with you that it's not a perfect analogy.
> His point is that it's a more useful and accurate analogy than saying
> "software development is X", for most _other_ values of X.

Yes, and that's like trying to reduce an elephant to a snake or a tree.

See: http://www.wordinfo.info/words/index/info/view_unit/1/?letter=B&spage=3

I think the first thing that happens when one encounters something new is trying to understand it in terms of previous experience. So, a football player who is suddenly thrust into the role of project manager may think "ok, it's just like a football game".

But you outgrow that state. As you see where the analogy breaks down you start to see the new thing as itself. The game analogy may be interesting if you're still trying to grasp what software development it. But it is just a step on the way.

Humans are tribal animals in almost every respect. We have to know our place in the tribe, and thus our level of responsibility. Some of us seek higher rank and therefore more responsibility, while others seek lower rank and more "freedom". We all measure ourselves by our accomplishments. To do otherwise would make moot the point of accomplishing anything, and make moot the point of even getting out of bed in the morning or driving innovation forward. If we simply did not care, we'd have no compulsion.

We will always rank ourselves based upon something, even if we create that "equal" society in which we are all free. I believe it was George Orwell in his "labored" classic Animal Farm who said: All animals are created equal. Some are just more equal than others.

And it is that which drives us. To say we're "crazy" for wanting anything else is sour grapes.

"Whenever I see a "X is Y" philosophy, I cringe. It reminds me of the blind men and the elephant. X is X. Your associations and feelings about X may be Y, but that doesn't make X Y. K?"

Well, sometimes, X is Y. For example, the set of euclidean transformations of the plane form a group. Of course, this business about viewing software development as a collaborative game is hardly a mathematical conjecture, but it is a somewhat neat idea, that might be more useful than waterfalls, or whirlpools or rugby scrums or whatever... If it isn't useful to you, disregard it. It's good for us blind men to at least talk about the elephant.

I would bet that if one really wanted to, one could construct a (perhaps not very good) model of software development as a non-zero-sum asymmetric game in extensive form. To put together anything that would be at all useful in varying situations(corporate development, open source) would require you to quantify a whole bunch of different,hard to quantify factors about human motivation. You'd probably want to use some kind of continuous choice space like they do in differential games(http://www.amazon.com/Differential-Games-Mathematical-Applications-Optimization/dp/0486406822), and have the different player's payoff functions be dependant on the current status of the project and their involvement in it.

There's certainly a lot to be said for recognizing that our models of the world are just models. However, that's pretty different from saying that we shouldn't attempt to make models at all. People from different backgrounds are going to communicate about their models differently. Someone without(or with!) any mathematical training coming back from Iraq might very well say "War is hell". Is that a statement of fact? There's a great deal of postmodernist heming and hawing we could do to try and answer that question, but I'm no postmodernist. What I think we can unequivocally say is that it's an observation. Just like the statement: "From my observations, it seems that one has a much greater probability of getting one's ass blown off in a war zone." You might be more comfortable accepting the latter as a statement of fact, but it's still just an observation...

I noticed a couple things from the games section of the article that seemed key to how this analogy ties together. First, games as mathematical constructs. Second, focusing on human behavior since humans are the critical path for any software development. If you consider that possibly the first and most common method of learning any human will ever employ is play (aka experimentation), staging a game geared towards optimizing human behavior patterns makes sense. Nash equilibriums are one example of how this type of analogy is used similarly in economics, though usually at much larger scales than the individual. Economists have the distinct advantage of having lots of data to play with in arriving at optimization strategies, software projects usually don't. Given that lack of analytical data, greater emphasis on psychology seems like a logical option.

Software development is a fairly general reference to a goal oriented activity. In practice, it's a process of interaction between a variety of smaller, more precise activities (ie design, programming, testing, debugging, configuring, packaging ...). These are all also verbs, which are a critical element of game design.

Games aren't necessarily about having fun. The prisoner's dilemma is a good example. Fun makes for an excellent motivating factor but it isn't necessarily the goal.

Overall I think the most important thing about the article is that it places emphasis on the psychology of human behavior in approaching the process of software development. Compared to the common paper trail and deadline centric approaches that seem to totally ignore the fact that people are the critical path to software development I'd consider any progress in this general direction a good thing.

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).

I have a lot of respect for Raph Koster as a design theorist, but not as an actual *game* designer. I was involved in Star Wars Galaxies from the early private beta in late 2002, and it was fascinating to watch how he handled our feedback after each testing session (early on, we only tested once a week, on Saturday mornings). I had several memorable debates with him over UI details.

I was fairly disillusioned by the time the game was released. Raph is incredibly intelligent, but for whatever reason, SWG was not really fun. Later I realized that what he'd built was not a game, but rather a Star Wars-themed economic simulator. And hey, that's fascinating in its own right, but it's not what we want from Star Wars, or even an MMO.

"it rewards anti-intellectual activity, as if it were. Rewarding bad behaviour only leads to more bad behaviour. "

That's a narrow, politcised, sense of "game". Perhaps if someone said "software development is co-operative hill-climbing", or "software development is co-operative foraging", it would resonate better with you. It won't surprise me if Cockburn turns out to be using rock climbing as a metaphor not for the game, but for the solution space the game is played in.

> Other things people measure themselves by: What car they drive, what iPod they have and the size of their house. I do think that all of that is done, and I stand by my assertion that if you measure yourself by any of them, you are crazy.

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.

I have been pondering the connection between game mechanics and software development for a few months now.

http://philoculture.blogspot.com/2007/01/fun-is-usable.html

To summarize, in MMORPGs such as World of Warcraft or Second Life, players "work" for free on a scale management can only dream of- the value of these games is largely provided free of charge. But why?

Because it is fun, of course, but then, why fun? The daily activities of a player in a MMORPG are not significantly different from the activities of any clerical worker in the global marketplace. How do we make people work like they play? The answer, as Koster notes, is fun.

I agree with Koster that the primary mechanism of fun is social and competitive, but most competent organizations are quite adept at setting up ladders and hierarchies for employees. I think that the social rewards exist already in most vital organizations.

What many modern companies have trouble doing is providing the instant feedback that games such as MMORPGs provide. Some set of metrics, observed by management software in real time and displayed unobtrusively across the IDE to employees, could provide the instant gratification of an MMORPG in a software development setting.

Like the rules of a good system, these metrics would be reviewed constantly by the user base, and adjusted if abuses are found- AKA "nerfing". Similarly, weak metrics could be strengthened on recommendation if the mechanics are found to unfairly weaken them, AKA "gimping".

>He is using the word "game" in the broadest sense imaginable.

Or, more accurately, in the "game theory" sense of the word, in which "A game consists of a set of players, a set of moves (or strategies) available to those players, and a specification of payoffs for each combination of strategies. [ - Wikipedia]

This definition reinforces the tradeoffs inherent in software development. E.g. if you spend a day writing document X, then that's a day you can't spend on document Y, or on the code itself. Each of the possible actions has a different payoff.

> > 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.

> 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.)

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

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.

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

I think the key concepts to understand here are that the success of a project depends on how well the people involved communicate and cooperate with each other and that software development models can be viewed as guides to creating 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 wouldn't do much for morale. You may as well carry around a whip.

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.