Cooperative games of invention and communication

Speak these words to yourself, slowly: “cooperative games of invention and communication”. Cooperative. Games. Of invention. And communication. That’s what software development is all about! You cooperate to invent something, for which you need to communicate (a lot) – and it’s not engineering, it’s a game!

Software Development Magazine published an article in February entitled “Games Programmers Play”, which was an excerpt from the first chapter of Alistair Cockburn’s book Agile Software Development, in which he suggests that we should regard software development as a game (although he acknowledges that he isn’t the first to do so), instead of as engineering or model building.

As for engineering, Cockburn writes that software development is too young and too rapidly evolving to be subject to comparison, because engineering is based “on centuries of tabulation of known solutions” and building something, for example a bridge, is not invention: “Given a river and a predicted traffic load, [the engineers] take soil samples and find [in the code book] the simplest structure that handles the required load over the given distance”.

But while using engineering as a reference merely doesn’t provide guidance, he writes, “characterizing it as model building leads directly to inappropriate project decisions. If software development were model building, then a valid measure of the quality of the software or of the development process would be the quality of the models, their fidelity to the real world, and their completeness.”

To return to the game metaphor, “[constructing] a model is interesting only if it helps win the game”, Cockburn writes. And models are but one “intermediate work product” that might help winning the game:

Intermediate work products are not important as models of reality, nor do they have intrinsic value. They have value only as they help the team make a move in the game. ... An intermediate work product is to be measured for sufficiency: Is it sufficient to remind or inspire the involved group?

So, intermediate work products are means to achieving the goals of the game, of which the primary goal is delivering working software. Another goal is, he writes, “to create an advantageous position for the next game, which is either altering or replacing the system or creating a neighboring system.” Producing documentation is of no interest to the current game, but to future games, which might either be played by a completely different team or at a later point in time when the original players have forgotten what the earlier game was all about.

Cockburn asks, “When does the team construct these additional work products?” and describes the two extremes, which he calls “continuous redocumentation” (constantly keeping the documentation up-to-date) and “just-never documentation” (never writing any). The answer to his question depends entirely on the context.

I like the game metaphor, because it emphasizes that it is something you do together, towards a common goal, as in playing football – although the “other team” isn’t people but, for example, “the market”, “time” and “other games”. As for other games, Cockburn writes that “[each] team member is playing an infinite game called career [and] may take actions that are damaging to the project-as-game but that [he/she views] as advantageous to [his/her career].” Then the company plays an infinite game, for which some moves might disadvantageous for the project’s game.

I think it’s important to realize that such moves in individuals’ and the company’s games are something that you have to live with. You can neither go along as if such things won’t happen, or struggle to prevent them. Instead, you must learn to adjust whenever they do.

Go ahead and read the article! I can’t write more about this now, but perhaps I’ll return to it in the future.