Toda buena elección técnica comienza con una pregunta incómoda: ¿cuáles son las restricciones reales? Mientras no respondas eso, cualquier comparativa es teatro. Terminas copiando el stack de una big tech y heredando sus problemas sin heredar ni su escala ni el equipo capaz de soportarlos.
El culto cargo sale caro
El culto cargo ocurre cuando aparecen aviones de madera porque alguien vio que los aeropuertos de verdad tenían pistas. En tecnología sucede lo mismo: adoptar Kubernetes, microservicios o esa base de datos NoSQL de moda porque una empresa famosa los usa, sin preguntarse por qué los usa.
El problema no es la herramienta. Es importar la solución sin importar el problema. Netflix tiene motivos concretos para su arquitectura. Tú, con tres desarrolladores y 200 usuarios, probablemente no tienes los mismos. Copiar el ritual no produce el resultado.
Empieza por las restricciones, no por el menú
La mayoría de las conversaciones sobre decisiones técnicas empiezan mal: por las opciones. «¿React o Vue?», «¿Postgres o Mongo?». Es como abrir el menú antes de saber si tienes hambre, dinero o alguna alergia.
Hazlo al revés. Escribe primero las restricciones reales:
- Equipo: ¿qué domina ya el equipo? ¿Es fácil contratar a alguien que sepa X en tu región?
- Plazo: ¿se puede aprender algo nuevo ahora o la fecha límite es la semana que viene?
- Operación: ¿quién va a mantener esto a las 3 de la madrugada?
- Datos y SLA: ¿cuál es el costo de perder o retrasar un registro?
Con las restricciones sobre la mesa, la mitad de las opciones se descarta sola. El menú se reduce y, entonces sí, la conversación se vuelve breve.
Un trade-off es una cuenta, no una opinión
No existe tecnología sin precio. Existe un precio que ves y otro que te alcanza después. Una elección equivocada no es la que tiene defectos; es aquella cuyos defectos descubriste demasiado tarde.
Para cada finalista, escribe qué exige: curva de aprendizaje, costo de operación, madurez del ecosistema, tamaño de la comunidad y lock-in. Una tabla poco estética en un archivo de texto ya vale más que una hora de debate en Slack, porque obliga a convertir cada opinión en una fila comparable.
Y cuidado con el sesgo del brillo: la herramienta nueva siempre parece resolverlo todo porque solo viste la demo, nunca la producción un viernes por la tarde.
Prefiere lo aburrido y comprobado
Ante una duda técnica, apuesta por lo aburrido. La tecnología aburrida es la que ya ha recibido suficientes golpes: tiene documentación madura, hay profesionales en el mercado que saben usarla y sus bugs están documentados en Stack Overflow desde 2018.
Postgres es aburrido. Un monolito bien organizado es aburrido. Una cola simple es aburrida. Y aburrido, aquí, es un elogio: significa predecible. Gastas tu presupuesto de innovación donde genera una ventaja de negocio, en lugar de reinventar la persistencia de datos.
La regla práctica: ten como máximo una o dos apuestas arriesgadas por proyecto. El resto debe ser tan poco llamativo que nadie tenga que pensar en ello.
Cuánto cuesta dar marcha atrás
El factor más ignorado en una decisión es el costo de deshacerla. Hay decisiones de dos vías: entras, pruebas y, si no te convence, vuelves sin secuelas. Y hay decisiones de una sola vía: una vez que cruzas, quedas comprometido y salir cuesta una migración de meses.
Cambiar de biblioteca de gráficos es una decisión de dos vías; decídelo rápido y no pierdas el sueño. Elegir la base de datos principal, el modelo de datos o el proveedor de cloud con todo el ecosistema acoplado es una decisión de una sola vía; ahí vale la pena medir tres veces.
Cuanto más irreversible sea la decisión, más rigor merece, y más conviene pagar para mantener abierta la salida —una capa de abstracción o un formato de datos portable—. Cuanto más reversible sea, más barato resulta decidir y seguir adelante.
Decide y escribe: el ADR
Una decisión que no se registra no existe: se convierte en una leyenda oral cuyo motivo nadie recuerda seis meses después. Escribe un ADR (Architecture Decision Record): un archivo breve dentro del propio repositorio, con el contexto, las opciones consideradas, la decisión y las consecuencias esperadas.
No tiene que ser bonito. Tiene que responder a la pregunta que alguien hará en el futuro: «¿Por qué demonios elegimos esto?». Con el ADR, la respuesta es un commit, no una reunión.
Elegir bien no significa acertar siempre. Significa decidir con las restricciones claras, anotar los trade-offs, evaluar el costo de reversión y dejarlo registrado. Así, cuando el contexto cambie —y cambiará—, revisas una decisión en lugar de hacer arqueología. Prefiere lo aburrido, escribe el porqué y sigue construyendo.