If Robbins defined the problem, John von Neumann gave it mathematics. In 1928, he published "On the Theory of Parlor Games." In 1944, with Oskar Morgenstern, he published Theory of Games and Economic Behavior. The connection to Robbins is direct. Robbins said economics is choice under scarcity. Von Neumann said: choice under scarcity, when the outcome depends on the choices of others, is a game.
If your choice were independent of others' choices, it would be optimization. Because it depends on others' choices, it is strategy. Strategy is optimization under uncertainty about what other players will do. Von Neumann's first contribution was the minimax theorem for zero-sum games: every two-player zero-sum game has an optimal strategy — minimize your maximum possible loss. In purely competitive situations, there is a rational strategy. Compute it. Follow it.
But most real situations are not zero-sum. Nash extended the framework in 1950 with the Nash equilibrium — a state where no player can benefit by unilaterally changing strategy, given what everyone else is doing. The equilibrium is not necessarily optimal. The Prisoner's Dilemma, formalized by Flood, Dresher, and Tucker, shows that individually rational strategies can produce collectively worse outcomes than cooperation. The gap between individual rationality and collective optimality is where economics lives. It is also where software architecture lives.
Schelling won his Nobel for a deceptively simple observation: in games without communication, people coordinate by finding what is obvious. The power is not in being right. It is in being obvious. The team that picks the most obvious API convention doesn't win because the convention is best. They win because everyone else predicted they would pick it. Obviousness is a coordination technology. The best architects don't design the optimal interface. They design the interface everyone will predict they designed. The prediction does the coordination. The interface just has to be what was predicted.
The definitions
Game. A set of players, strategies for each, and a payoff function mapping strategy combinations to outcomes. Your microservices architecture is a game. Players: services. Strategies: API designs, deployment schedules, dependency choices. Payoffs: uptime, throughput, maintainability.
Zero-sum game. One player's gain is another's loss. Total payoff constant. Fixed headcount across teams is zero-sum: every hire for Team A is a hire Team B doesn't get.
Non-zero-sum game. Players can both gain or both lose. Total payoff varies with cooperation. Most software situations are non-zero-sum. Both teams benefit from a clean API. Both lose from a broken one.
Cooperative game. Players can form binding agreements. An SLA with penalty clauses is a binding agreement. Non-cooperative: no binding agreements. API contracts without automated testing are cheap talk. Cheap talk doesn't change equilibria.
Perfect information. Each player knows all previous moves. Monolith: every module can see every other module's state. Imperfect information: players don't know all previous moves. Microservices: Service A doesn't know Service B's internal state. Imperfect information produces coordination failures. The failures are not bugs. They are properties of the information structure.
Simultaneous game. Players choose without observing others. Teams making independent technology choices in the same quarter. Sequential game: players move in turn, observing previous moves. Deployment ordering is sequential. The first mover sets the environment. The Stackelberg leader has advantage.
Dominant strategy. Best regardless of what others do. Rare in real situations. When it exists, decision-making simplifies to triviality. When it doesn't, you need a model of the other player.
Pareto optimality. No player can be made better off without making another worse off. The Nash equilibrium of the Prisoner's Dilemma is not Pareto optimal. Many architectures are stuck in Pareto-suboptimal equilibria. The system is at a Nash equilibrium. The equilibrium is suboptimal. Moving requires coordination. Coordination is costly. The cost keeps the system where it is.
Stag hunt. Everyone benefits from cooperation but only if everyone cooperates. Hunting a stag requires all hunters. Hunting a rabbit can be done alone. The stag is worth more. If any hunter defects, the stag escapes and cooperators get nothing. API standardization is a stag hunt. If all teams adopt, everyone benefits. If some defect, the standard fragments. The stag was worth more. Nobody got it.
Chicken. Two players drive toward each other. First to swerve loses. If neither swerves, both crash. Two teams both rewriting the same service. Neither backs down. Both ship incompatible rewrites. The system breaks. Someone must swerve. Organizational hierarchy determines who. The hierarchy is a mechanism for resolving Chicken.
Battle of the sexes. Two players want to coordinate but prefer different coordinated outcomes. Both prefer coordination to miscoordination. Choosing a shared message queue: both prefer either queue to no queue. Both prefer their own choice. Two Nash equilibria. The selected equilibrium depends on who moves first or has more power. The selection is political. The politics are game-theoretic.
Mechanism design. Reverse game theory. Start with the desired outcome. Design the rules that produce it. If you want teams to keep API contracts stable, design a system where breaking a contract is immediately visible and costly. Automated contract testing is mechanism design. Deployment friction is mechanism design. Design the rules. Don't plead for the outcome.
Evolutionary game theory. Strategies that perform well survive. Strategies that perform poorly die. John Maynard Smith (1982): an Evolutionarily Stable Strategy cannot be invaded by a mutant. Microservices survived because they resist being re-monolithed. The monolith didn't survive because a small team could extract a service and demonstrate value. The extraction was the mutation. The mutation spread. The population shifted. The shift was evolutionary.
Signaling game. One player has private information and takes an action that may reveal it. Writing a detailed RFC signals competence. A costly signal separates sincere from insincere types. Requiring a prototype before architecture review is a screening mechanism. The cost of the signal is the price of credibility.
Repeated game. The same game played multiple times. Sprints are repeated games. Repeated games enable reputation and reciprocity. The shadow of the future disciplines present behavior. Cooperation can be sustained in repeated games even when it collapses in one-shot games. This is why teams that work together for years develop trust. The trust is game-theoretic. The game is repeated.
Robert Aumann, who shared the 2005 Nobel with Schelling, proved the Folk Theorem: any feasible, individually rational outcome can be sustained as an equilibrium when the game is repeated infinitely. In his own words: "In a single encounter, confrontation is the logical move; but when the interaction will occur repeatedly, cooperation is the logical behavior." The shadow of the future disciplines the present. Teams that will work together for years develop trust not because they are virtuous but because defection today costs cooperation tomorrow. The trust is game-theoretic. The game is repeated.
This is part 2 of a 7-part series on scarcity and software.
- Part 1: On Scarcity
- Part 3: On Software Engineering Economics
- Part 4: On Games in Software
- Part 5: On AI and Mechanism Design
- Part 6: On Practice
- Part 7: The Catalog of Games
References:
- John von Neumann and Oskar Morgenstern, Theory of Games and Economic Behavior, Princeton University Press, 1944.
- John Nash, "Equilibrium Points in N-Person Games," Proceedings of the National Academy of Sciences, 1950.
- John Maynard Smith, Evolution and the Theory of Games, Cambridge University Press, 1982.
Scarcity is the universal engineering constraint. Time, attention, compute, complexity — every engineering decision is made within a budget. The budget is economic. The engineer who doesn't track the budget makes decisions blind. The engineer who tracks it makes decisions with full knowledge of the trade-off. The trade-off is the decision. The budget is the constraint. Scarcity is the unifying principle.