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 es estratégico, no de falta de conocimiento técnico. Hace falta un marco mental para pensar antes de decidir.
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 nombrar esas estrategias antes de discutir herramientas, propongo un marco mental que llamo principio RPS (Rock–Paper–Scissors): clasifica 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 referirse a estos enfoques de forma compacta, en este marco se les llama piedra, papel y tijeras (Rock, Paper, Scissors). Como en el juego, cada uno brilla en ciertos contextos y resulta caro 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. Podrían haber sido Terran, Protoss y Zerg o cualquier otra triada.
A continuación, 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.
Poco elegante, poco brillante, y funciona: prioriza 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.
Un ejemplo rápido
Imagina que necesitas persistir datos para un MVP que validará si hay mercado.
- Piedra: SQLite o un JSON en disco. Rápido, reversible, suficiente mientras no sepas si el producto despega.
- Papel: PostgreSQL gestionado con backups y migraciones desde el día uno. Tiene sentido si ya tienes usuarios de pago o datos que no puedes perder.
- Tijeras: Diseñar sharding, réplicas y un modelo de datos pensado para millones de filas. Solo si el problema central ya es la escala.
La pregunta útil es qué estrategia se está usando y si el contexto lo justifica, no cuál es más profesional.
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, actuar antes de que exista el problema)
- Criticar una piedra por no ser elegante, cuando era la decisión correcta para ese momento. Basta 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, con el esfuerzo que conlleva, 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 en versión PaaS como en modo self-hosting. Si se elige Firebase en lugar de Supabase, es más difícil cambiar de estrategia, porque Firebase ancla a su plataforma y hace costoso pasar de un backend delegado en terceros (Papel) a autoalojarlo 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.
Lo que importa es elegir conscientemente y mantener opcionalidad cuando importa, no coronar siempre “la mejor” estrategia.
Qué viene después
En otros posts de este blog el marco se aplica a decisiones concretas (como atajo mental, no como regla fija):
- 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), ya en snowflake e IaC, cloud-first y acceso al homelab.
- Lenguajes de programación (Python/TypeScript/Ruby/PHP, Java/C#, y Golang/Rust/Elixir)
- Decisiones que surgen a diario, aunque no se les ponga ese nombre.
No para decirte qué usar. Sino para dejar claro qué estás pagando cuando eliges.
Este post desarrolla el criterio planteado en la presentación.