Alistair Cockburn maintains that software development is a cooperative game:
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2007/03/software-development-as-a-collaborative-game.html
Alistair Cockburn maintains that software development is a cooperative game:
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”.
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?
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.
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.
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.
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.
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.
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.
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”.
“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…
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.
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.