La mayoría de las discusiones técnicas no fallan por falta de conocimiento. Fallan porque las partes implicadas están jugando a estrategias distintas sin darse cuenta.

Uno defiende “lo simple que funciona”. Otro exige “algo sólido y mantenible”. Un tercero quiere “hacerlo bien de una vez”.

La discusión se vuelve moral, dogmática o personal. Aparecen palabras como best practices, overengineering, chapuza, futuro, profesional. Y nadie se entiende.

El problema no es técnico. Es estratégico. Y requiere de un marco mental para ayudar a pensar antes de tomar decisiones.

No existe la estrategia óptima universal

En ingeniería (software, sistemas, tooling, arquitectura) no existe una solución que gane siempre. Existen trade-offs: riesgo, coste, recompensa, reversibilidad, complejidad.

Lo que sí existe es una tendencia constante a discutir como si hubiera una única decisión correcta y todo lo demás fueran errores o incompetencia.

Para evitar ese marco falso, propongo el principio RPS (Rock–Paper–Scissors): un marco mental para clasificar decisiones técnicas o estratégicas según qué priorizan y qué sacrifican.

No te dice qué elegir. Te obliga a saber qué estás eligiendo.

El principio RPS

El principio RPS parte de una idea simple: toda decisión relevante cae —explícita o implícitamente— en uno de tres arquetipos estratégicos.

Para poder referirme a estos enfoques de forma compacta los etiqueto como piedra, papel y tijeras (Rock, Paper, Scissors). Como en el juego, cada uno gana en ciertos contextos y pierde en otros.

Las etiquetas piedra, papel y tijeras son solo nombres memorables; no heredan las reglas del juego original ni implican relaciones fijas entre ellas. He puesto las etiquetas de piedra, papel y tijeras como podría haber puesto Terran, Protoss y Zerg o cualquier otra triada.

Dicho esto paso a presentar cada una de las tres estrategias de RPS:

🪨 Piedra (Rock): Pragmatismo suficiente

Piedra es la estrategia de “esto funciona y seguimos adelante”.

• Minimiza el tiempo de decisión.
• Reduce el coste cognitivo.
• Resuelve el problema inmediato sin aspirar a optimizarlo todo.

No es elegante. No es brillante. Pero funciona. Es la estrategia de priorizar avance inmediato sobre refinamiento.

Es la estrategia correcta cuando:

• El coste de pensar más es mayor que el coste de equivocarse un poco.
• El problema no es central.
• La reversibilidad es alta.
• Ideal para prototipos y MVPs

Piedra suele ser criticada por no ser “limpia” o “correcta”. Muchas veces, esa crítica es puro ruido.

📄 Papel (Paper): Control de riesgo pagando un precio

Papel prioriza estabilidad, previsibilidad y control del riesgo.

• Más trabajo inicial.
• Más restricciones.
• Menos sorpresas a largo plazo.

Es la estrategia de quien dice: “prefiero pagar ahora para no pagar después”.

Funciona bien cuando:

• El fallo es caro.
• El sistema va a vivir mucho tiempo.
• El contexto es hostil al cambio.

Papel suele ser acusado de lento o burocrático. A veces lo es. A veces es simplemente realista.

✂️ Tijeras (Scissors): Potencial a largo plazo pagando riesgo

Tijeras busca el máximo potencial a largo plazo.

• Más flexibilidad.
• Más rendimiento.
• Más complejidad.
• Más riesgo.

Es la estrategia del “si vamos a hacerlo, hagámoslo bien”.

Puede ser la mejor jugada… o un ejercicio de overengineering inútil si el contexto no lo justifica.

Tijeras falla cuando se usa por ego técnico o por alergia a lo simple.

De dónde vienen los problemas

La mayoría de los problemas no vienen de elegir mal, sino de no saber qué estrategia se está usando.

Algunos patrones clásicos:

• Usar tijeras cuando hacía falta piedra (lo perfecto es enemigo de lo bueno).
• Usar papel por miedo, cuando el coste real del fallo era bajo. (Ponerse la venda antes que la herida)
• Criticar una piedra por no ser elegante, cuando era la decisión correcta para ese momento. Pensemos en el caso de La fábula del columpio: sirve como metáfora de las situaciones donde un cliente necesita una solución sencilla y se hace todo tipo de ingeniería mal aplicada, cuando lo que realmente necesitaba es una solución simple y rápida aunque poco elegante, suficiente para ese contexto.

Cuando no se habla de estrategia, se discute de forma religiosa.

Puentes y Anclas

El principio RPS no está completo sin dos conceptos transversales.

Puentes 🌉 Decisiones que reducen el coste de cambiar de estrategia más adelante. Ejemplos típicos: software libre, posibilidad de self-hosting opcional, estándares abiertos, formatos interoperables, contenedores.

No te obligan a elegir bien ahora. Te permiten corregir después.

Por ejemplo: si eliges Supabase para tener pronto un backend para tu aplicación y en algún momento se te va de precio, tienes la opción de autoalojar una instancia propia en tu VPS en lugar de usar la versión PaaS. Esto es gracias a que Supabase tiene dos puentes: es software libre y se puede usar tanto como PaaS como en modo self-hosting. Si nos hubiéramos decantado por Firebase en lugar de Supabase, sería más difícil cambiar de estrategia, porque Firebase te ancla a su plataforma y hace costoso pasar de usar un backend delegado en terceros (Papel) a alojarlo nosotros mismos en un VPS (Piedra).

Anclas ⚓ Decisiones que encarecen o bloquean ese cambio. Vendor lock-in, software cerrado, protocolos propietarios, dependencias rígidas.

Pueden ser convenientes a corto plazo. Pero convierten decisiones reversibles en apuestas.

La diferencia entre una decisión inteligente y una trampa suele estar aquí.

Para qué sirve todo esto

El principio RPS no pretende crear una nueva ortodoxia. Hace justo lo contrario.

Sirve para:

• Pensar en términos de trade-offs, no de dogmas.
• Aceptar que toda estrategia gana algo y pierde algo.
• Separar discusiones técnicas reales de discusiones ideológicas disfrazadas.

La habilidad no está en elegir siempre “la mejor” estrategia. Está en elegir conscientemente y mantener opcionalidad cuando importa.

Qué viene después

En los próximos posts aplicaré este marco a decisiones concretas:

• Distribuciones Linux (Debian podría representar piedra, RHEL papel, y Arch tijeras).
• IDEs (VSCode, IntelliJ IDEA, y LazyVim/AstroNvim/NvChad)
• Infraestructura (VPS piedra, Cloud papel, Bare metal tijeras)
• Lenguajes de programación (Python/TypeScript/Ruby/PHP, Java/C#, y Golang/Rust/Elixir)
• Decisiones que todos tomamos, aunque no las llamemos así.

No para decirte qué usar. Sino para dejar claro qué estás pagando cuando eliges.