“A software project has much in common with rock climbing. The primary goal is to deploy the system. It is with respect to this goal that the team is first evaluated. After that, one may ask whether it was a fun project, or well-run, or the program is aesthetic or maintainable. If the team does not deliver the software, however, the project is generally considered a failure. (Note: it is possible – and often a good idea – to abandon the game in the middle when detecting that the goal no longer worthwhile.)
One notable difference between software projects and rock-climbing is that software projects come in series and build upon each other in ways that climbing trips do not. In software, a team will alter the deployed system, or develop an adjacent system that interfaces with it.
Thus, unlike a rock-climbing trip, a software project has two goals: To deliver the system; To set up for the next game.”
End of Software Engineering and the Start of Economic-Cooperative Gaming –
Cockburn points out that climbing or mountaineering and software development are both goal-terminated (finite) collaborative games.
Actually the latter statement isn’t entirely true. Many climbs, while worthwhile goals in their own right may also be considered as stepping stones to subsequent climbs by the participants. At one end of the spectrum is the “training” climb. Like a prototype such a climb is only undertaken to learn skills for a subsequent, harder objective.
While Cockburn doesn’t consider software development a high risk game like climbing one could argue that software development is a game of high stakes. Unlike many games, climbing and software development are games in which the participants are playing for more than they can afford to loose – potentially their jobs.