Cockburn recently had an article in Software Development magazine (I think it is an excerpt from the giveaway book) that uses the metaphor of software development being a game. As I recall he says the two main goals are to 1) win the game (successfully develop and deploy software) and 2) get yourself in position to play again (do some more development). I'll see if the article is on the SD website and post a link if it is. Any thoughts on this analogy/metaphor? John
The only reason for time is so that everything doesn't happen all at once.
- Buckaroo Banzai
I think a more interesting question is whether game theory or system dynamics applies to software development. I only know some of the basics of game theory, but I certainly see some of the lessons applying (and recently helped to teach one of those lessons to some kids at MIT). Interesting historical note: the founder of system dynamics, Jay Forrester (MIT '45), invented random-access magnetic-core memory, left the computer field because he felt that all the significant innovations had already been made.
Well game theory is a model for some physical process ... and definitely some of the things suggested in the article is true ...
Joined: Apr 05, 2000
I would think you could apply game theory to software development. People apply it to study/model economics, poly sci/politics, military strategy and I think s/w development has similarities to these fields if for no other reason than you have people interacting. One of the most interesting (?) things I have found about the software industry is the view from outside vs. what actually happens (in most cases). When you talk with people they think we all sit in dark rooms by ourselves just coding away. In most of the jobs I have had, working with the other people/groups/organizations has taken more time (well, it sure seems like it ) than writing and testing the software. So it seems credible that game theory might be a reasonable tool. Now I'll have to read up on game theory... John
I like the game and goal-achieving metaphor . So it requires people to be cooperative and communcate each other. The goal is the motivation. Also the game requires creativity, since every game differs. The rules of game are your requirements. [ February 21, 2002: Message edited by: Doug Wang ]
Creativity is allowing yourself to make mistakes. Art is knowing which ones to keep
Originally posted by Guillaume Compagnon: in a game, there are winners and ... loosers
aside, software development does not fall into this category of games. As Alistair explains in his book, software development is a cooperative, goal-seeking game where "people work either to win together or to continue the game as long as they consider it worth playing." "Losing" in this game means not meeting the goals, which means nobody wins... Junilu [ February 21, 2002: Message edited by: Junilu Lacar ]
Originally posted by Doug Wang: I like the game and goal-achieving metaphor...The rules of game are your requirements.
I have read the first two chapters of the preview book. I am still trying to digest and reflect on most of what I read--and this is going to take a while since the first few chapters are more abstract--but Alistair seems to make a distinction between a metaphor and what he calls a "comparison partner". My impression is that Alistair does not see "cooperative and goal-seeking game" so much as a metaphor but as something else. Right now, that "something else" as I understand it is another way of "seeing" what software development really is (vs. what it is like if we take it as a metaphor). Why make the distinction between metaphor and "comparison partner"? Junilu
The reason to distinguish between a metaphor and a comparison partner is to affect how people use the two.
With a metaphor, one pretends the one *is* the other, and all the mental links about the one are applied to the other in a mapping. With a comparison partner, the two are both elements of something else, and so have parallels. Software *is* a cooperative game - or, as someone here wrote, when you put on glasses colored with the "cooperative game" filters, the actions on project shine through. In that sense, it might be a metaphor. In any case, it gives us a vocabularly. Rock climbing is not a metaphor for software development. Or at least, if it were, one would talk about, "What stage of the climb are we in? Are our anchors secure? How much light is there? Are the belays in place?" etc. Which doesn't do much for me as a programmer. Alistair