Most technical discussions don’t fail because of a lack of knowledge. They fail because the people involved are playing different strategies without realizing it.
One defends “the simple thing that works.” Another demands “something solid and maintainable.” A third wants “to do it right the first time.”
The discussion turns moral, dogmatic, or personal. Words like best practices, overengineering, hack, future, and professional start flying around. And nobody understands each other.
The problem isn’t technical. It’s strategic. And it calls for a mental framework to help you think before making decisions.
There is no universally optimal strategy
In engineering (software, systems, tooling, architecture) there is no solution that always wins. There are trade-offs: risk, cost, reward, reversibility, complexity.
What does exist is a constant tendency to argue as if there were a single correct decision and everything else were mistakes or incompetence.
To avoid that false frame, I propose the RPS (Rock–Paper–Scissors) principle: a mental framework for classifying technical or strategic decisions according to what they prioritize and what they sacrifice.
It doesn’t tell you what to choose. It forces you to know what you are choosing.
The RPS principle
The RPS principle starts from a simple idea: every relevant decision falls—explicitly or implicitly—into one of three strategic archetypes.
To refer to these approaches compactly, I label them rock, paper, and scissors. As in the game, each wins in certain contexts and loses in others.
The labels rock, paper, and scissors are just memorable names; they don’t inherit the rules of the original game or imply fixed relationships between them. I chose rock, paper, and scissors as I could have chosen Terran, Protoss, and Zerg, or any other triad.
With that said, here are the three RPS strategies:
🪨 Rock: Sufficient pragmatism
Rock is the strategy of “this works and we move on”.
- Minimizes decision time.
- Reduces cognitive cost.
- Solves the immediate problem without trying to optimize everything.
It’s not elegant. It’s not brilliant. But it works. It’s the strategy of prioritizing immediate progress over refinement.
It’s the right strategy when:
- The cost of thinking more is greater than the cost of being slightly wrong.
- The problem isn’t central.
- Reversibility is high.
- Ideal for prototypes and MVPs.
Rock is often criticized for not being “clean” or “correct.” Often, that criticism is pure noise.
📄 Paper: Risk control at a price
Paper prioritizes stability, predictability, and risk control.
- More upfront work.
- More constraints.
- Fewer surprises in the long run.
It’s the strategy of someone who says: “I’d rather pay now than pay later”.
It works well when:
- Failure is expensive.
- The system will live a long time.
- The context is hostile to change.
Paper is often accused of being slow or bureaucratic. Sometimes it is. Sometimes it’s simply realistic.
✂️ Scissors: Long-term potential at the cost of risk
Scissors seeks maximum long-term potential.
- More flexibility.
- More performance.
- More complexity.
- More risk.
It’s the strategy of “if we’re going to do it, let’s do it right”.
It can be the best move… or a useless exercise in overengineering if the context doesn’t justify it.
Scissors fails when used out of technical ego or an allergy to simplicity.
Where problems come from
Most problems don’t come from choosing badly, but from not knowing which strategy is being used.
Some classic patterns:
- Using scissors when rock was needed (the perfect is the enemy of the good).
- Using paper out of fear, when the real cost of failure was low. (Putting on the bandage before the wound.)
- Criticizing a rock for not being elegant, when it was the right decision for that moment. Think of The Tree Swing cartoon: it serves as a metaphor for situations where a client needs a simple solution and all kinds of misapplied engineering gets built, when what they really needed was a simple, quick solution—even if inelegant—sufficient for that context.
When strategy isn’t discussed, the debate turns religious.
Bridges and Anchors
The RPS principle isn’t complete without two cross-cutting concepts.
Bridges 🌉 Decisions that reduce the cost of changing strategy later. Typical examples: free software, optional self-hosting, open standards, interoperable formats, containers.
They don’t force you to choose well now. They let you correct course later.
For example: if you choose Supabase to quickly get a backend for your application and at some point the price gets out of hand, you have the option to self-host your own instance on your VPS instead of using the PaaS version. That’s thanks to Supabase having two bridges: it’s free software and can be used both as PaaS and in self-hosted mode. If we had gone with Firebase instead of Supabase, it would be harder to change strategy, because Firebase anchors you to its platform and makes it costly to move from a third-party backend (Paper) to hosting it ourselves on a VPS (Rock).
Anchors ⚓ Decisions that make that change more expensive or block it entirely. Vendor lock-in, closed software, proprietary protocols, rigid dependencies.
They can be convenient in the short term. But they turn reversible decisions into bets.
The difference between a smart decision and a trap is usually here.
What this is for
The RPS principle doesn’t aim to create a new orthodoxy. It does the opposite.
It helps you:
- Think in terms of trade-offs, not dogmas.
- Accept that every strategy wins something and loses something.
- Separate real technical discussions from ideological debates in disguise.
The skill isn’t in always choosing “the best” strategy. It’s in choosing consciously and preserving optionality when it matters.
What comes next
In upcoming posts I’ll apply this framework to concrete decisions:
- Linux distributions (Debian could represent rock, RHEL paper, and Arch scissors).
- IDEs (VSCode, IntelliJ IDEA, and LazyVim/AstroNvim/NvChad)
- Infrastructure (VPS rock, Cloud paper, Bare metal scissors)
- Programming languages (Python/TypeScript/Ruby/PHP, Java/C#, and Golang/Rust/Elixir)
- Decisions we all make, even if we don’t name them that way.
Not to tell you what to use. But to make clear what you’re paying when you choose.