--- title: "Piedra, papel y tijeras: un marco para decisiones técnicas" description: "El principio RPS: clasificar cada decisión técnica en pragmatismo (rock), control del riesgo (paper) o máximo potencial (scissors)." date: 2026-01-17 locale: es url: https://escribano.dev/es/blog/002-rps-principle/ --- 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](https://en.wikipedia.org/wiki/Tree_swing_cartoon): 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](https://supabase.com/) 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](https://en.wikipedia.org/wiki/Platform_as_a_service). 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](/blog/003-snowflake-iac-rps/), [cloud-first](/blog/004-cloud-first-problem/) y [acceso al homelab](/blog/006-homelab-vpn-access/). * 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](/blog/001-introduction/).