Software Development Asa Cooperative Game

See also NomicGame, StoneSociety, PlanningGame.

How I currently view software development (AlistairCockburn, 1999).

I put this here to foment discussion and some thought rubbing. The shortest version is the paragraph below, next shortest is the "manifesto" [1], then there is the 1-hour 'AlistairsScumTalk' [2] and the book version [3].

Software development is a cooperative game, in which people use markers and props to inform, remind and inspire themselves and each other in getting to the next move in the game. The endpoint of the game is an operating software system; the residue of the game is a set of markers to inform and assist the players of the next game. The next game is the alteration or replacement of the system, or creation of a neighboring system. -- AlistairCockburn

It's a nice statement, but perhaps you should elaborate more on cooperation. -- StuartBarker

What new insights do you gain by applying this view to software development? (honest question, not a rhetorical one) -- FalkBruegmann

I learn a lot about the economics and moves appropriate to make on a project. Here's how:

A game consists of a set of moves or movements. A competitive game is one in which a subset of the players win, the others lose. A cooperative game is one in which the players all help each other. Examples of cooperative games are rock climbing and playing music. The "game" is for the players to help each other complete the climb. In software development, the game is to deliver the software. The players are there to help each other complete the software. -- Alistair

I know it shouldn't be necessary, but it wouldn't hurt to add a reminder that, in a cooperative game, either everyone wins (software that meets the user's needs is delivered) or everyone loses (software is not delivered or does not meet users needs) together. The value of a particular player's win or loss will vary. -- DonaldMcLean

The real target of the manifesto is to set up how we view all the intermediate work products we produce. I have yet to interview a project in which they were kept consistent (with the exception of ChryslerComprehensiveCompensation, which, knowing that, deliberately set the number of intermediate work products needing maintenance to zero). Most people I have met bemoan this situation. I wish to establish that it is normal and proper and should be dealt with in a certain way.

The only real purpose of the intermediate work products is to help the team make their next move in the game. They have no intrinsic value (they may have competitive value as intellectual property). They are not important as models of reality. They serve only as they serve to help the team create the final work product. They either:

remind a team member of what they, in principle, already know, probably from some earlier discussion, in which case the marker need only be complete enough to actually remind the person of the thought or decision. For different people with different backgrounds, different markers are appropriate. What is important is, what is needed to remind the particular teammates of this particular thing.
inform the teammate(s). As with reminders, different forms of marker will work to inform people of different backgrounds the same thought. A marker need only be well-formed enough to perform its duty. An expert in the topic will only need a few words or a sketch; a newcomer to the topic may need many pages or drawings, or textbooks, or courses. What exactly is needed must be determined on each project, with each team.
serve to incite or inspire new thoughts, thought and ideas that will move the team to a better position in the game. These intermediate work products are 'props' in the game, props which help to draw the people out of themselves, to share and generate new ideas. The props need only be sufficient to their tasks. Paper cut-outs, sticky tape, mock-ups, sketches on whiteboards, mini-plays, all may work as props.

Unfortunately, this isn't always true. For systems that have unusual safety requirements, such as traffic control systems, intermediate products would become games in themselves. -- DonaldMcLean

The main thing is that there is no intrinsic value to measuring the intermediate work product for "completeness" or "perfection". An intermediate work product might be measured for "sufficiency" - was it sufficient to remind, inform or inspire? Any amount of effort or detail beyond sufficiency is extraneous to the purpose of the team and the purpose of the work product - perhaps it may show up in the "residue", but that is a different topic.

The software development game is played in a milieu of many other games, personal and organizational. One of the other games being played is to be able to play the next round. That is, having once deployed a software system, to set up for changing, replacing, augmenting or complementing it. Therefore, there is a residue to the game: a set of markers that will inform and remind the players of the next game. The players of the next game will know a different amount from the players of this game, and so what counts as "sufficient" for the next team is different from what counted as "sufficient" for this team. -- AlistairCockburn

PeteMcBreen points out that I omitted a most important residue and intellectual asset - the heads of the developers at the end of the project! Thanks for that addition. -- Alistair

Hmmm - this becomes more interesting to me in light of some comments at a meeting of the ChicagoPatternsGroup while reading/discussing BigBallOfMud (a.k.a. BBOM) by BrianFoote and JosephYoder (in the PLOP'97 proceedings). BBOM talks about recurring practices that are common and seem terribly unwise to us Engineer/Developer types. Yet they don't always end in failure, and recur so often that the authors of BBOM felt these practices deserved deeper investigation.

That such seemingly unsound things would be done deliberately certainly sounds like some sort of game to many, I am sure. Abraham MaslowsHierarchyOfNeeds came up during our discussion. The beginning of SteveMcConnell's book SoftwareProjectSurvivalGuide (SPSG) also discusses MaslowsHierarchyOfNeeds, and McConnell proposes a roughly corresponding HierarchyOfNeeds? for software development.

It was suggested that perhaps some of the deliberately short-sighted and seemingly "penny-wise but pound-foolish" decisions may simply be the best that can be managed at the time. We may have to start out this way, and figure out how to afford ourselves more "breathing room" to go back and refactor things later, and/or look and think a little farther ahead than we could afford to do the last time.

This is where the direct analogy to "playing a game" was raised: the "number of moves" that one could currently afford to lookahead in the software development game might correspond directly the project's current "level" in this software development HierarchyOfNeeds?. It's all part of the game that has to combine not just technical judgement and strategy, but also marketing, and project management and business cycles and profit, etc.

In this light, we thought BBOM was describing strategies for how to do certain things at various levels of the HierarchyOfNeeds? that would fit your immediate constraints, and would help afford you more time to get to the next level, and see more moves ahead (even though the strategy might be seen as shoddy practice from the long-term technical perspective).

Does this sound directly related to SoftwareDevelopmentAsaCooperativeGame? -- BradAppleton

This reminds me of some dimly-remembered bits of numeric analysis: for certain methods of calculating an integral, you need a seed "guess" at the integral's value. It doesn't have to be a good guess at all; from that guess, the algorithm can begin iterating toward the true solution. Software can be like that; the act of writing a bad solution can lead you toward a good solution.

From a recent exchange:

"I have a currently popular (with me) theory about software development, which I'll cite until I discover its shortcomings:

Sw development is a (usually resource limited) cooperative game of invention and communication having a primary and a secondary goal. The primary goal is to deliver the running system. The secondary goal is to set up for the next game, which will be to evolve or maintain the system, or to develop an adjacent system.

Fail to reach the primary goal, and the secondary goal doesn't much matter. Achieve the primary goal and fail on the second goal, and you win this game, stand to lose the next game (witness C3).

Given the resource limited nature of the game, you stand to lose the first game if you allocate resources to the second goal too early or too heavily, without getting the first goal safe.

Ergo, and this is the nice thing about this theory - it hands out predictions - what Ron said makes sense (that the XP Customer should write requests for documentation on Story Cards).

Someone needs to make a competitive analysis of how many resources, when, should pump up the documentation for the next game. Who should do that? I'm not sure, and it is possible that the Customer doesn't have the right stake in the game(s) to make the call correctly.

But the point is, most people think (a) that writing lots of documentation either makes reaching the primary goal safer, or (b) that writing lots of it early is necessary. Neither is true.

XP has shown that writing it early is not globally necessary for reaching the primary goal - delivery.

The other part to get is that producing documentation for the next game is an activity that competes for resources with producing the running system. I.e., the two, resource-competitive activities need to run and managed as such.

Having the Customer write the need for documentation on a Story Card is a good start - it certainly reveals the competition for resources. The only part I'm not sure about is whether it is the Customer who receives the forthcoming system who should make the cost call on functionality vs. documentation for the next round of games.

cheers -- AlistairCockburn

Do he have it down to a science or what?

This article (originally found at http://members.aol.com/humansandt/papers/asgame/asgame.htm) (BrokenLink) inspired SoftwareDevelopmentComparedToJazz. -- MichaelLeach

This may be a little naive, but, just for the sake of discussion, is source code part of the goal, or a marker for the next game? The line seems blurry.

Interesting question. To my stinking pragmatic eyes, publishing (compiling and deploying) the source code is the goal, so the source code is the primary goal. However, the structure, the beauty aesthetics simplicity clarity and expressiveness of the source code is "obviously" part of the secondary goal - setting up for the next game. If you know there's no next game, write the crap and publish it and chuck the source as fast as possible. If you know there'll be a second game, attend to the cost of revisiting the code. If you're not sure, hedge your bet in whichever way you feel up to ("ya rolls yer dice and ya takes yer chances") -- AlistairCockburn

References:

[1] http://alistair.cockburn.us/Cooperative+game+manifesto+for+software+development

Each of the following can be considered to be a BrokenLink; it seems AOL has shutdown the site formerly known as "Hometown"

Perhaps you can find this information where you can find AlistairCockburn's contributions:

HomePage
- http://alistair.cockburn.us/
Articles
- http://alistair.cockburn.us/Articles
Blog
- http://alistair.cockburn.us/Blog