You’ve been in this meeting.
Six engineers. A whiteboard. Someone draws a clean architecture: one service, a relational database, a well-defined API. It handles every requirement in the spec.
Then the questions start. “What about international customers?” “What if we need a second payment provider?” “Shouldn’t this be event-driven?”
45 minutes later, the single-service design has evolved into four microservices, an event bus, and a configuration system for scenarios nobody has actually requested. The system that could have been built in three weeks will now take three months.
Nobody wanted this outcome. Every question was reasonable. Every addition was defensible.
So what happened?
I spent a long time thinking about this problem, and the answer turned out to be in a field I didn’t expect: game theory. Architecture reviews are social games with real status stakes. The prisoner’s dilemma maps directly onto them. Building a comprehensive plan makes you look thorough. Building something simple makes you look lazy. So everyone over-engineers, and the whole team loses.
But game theory doesn’t just diagnose problems. It fixes them. A branch called mechanism design asks: how do you rewrite the rules of a game so the winning strategy produces the outcome you actually want?
That’s what this essay is about. Three questions you can throw into any spiraling design review that change the direction of the conversation in seconds. Not principles. Not best practices. Concrete questions that restructure who wins the status game in the room, so that simplicity becomes the rational choice.
If you’ve ever watched a clean design get buried under hypothetical requirements, this one’s for you.
The full essay is over on my Simplicity-First Philosophy publication:
