Estoy seguro de que la luna es de queso

Dijo alguien al pasar. La respuesta no tardó en llegar:

— Bueno, el análisis espectrográfico y el cálculo de órbitas niegan eso. Además, construimos un cohete, llevamos gente ahí y no pudieron comerla.

— Bla bla bla. Sigo pensando que es de queso.

La escena es absurda, pero bastante precisa. Una afirmación puede lanzarse en dos segundos, con total liviandad, y desarmarla puede requerir evidencia, método, explicación, paciencia y una cantidad ridícula de energía.

A eso se lo conoce como el Principio de Brandolini, o principio de asimetría de la estupidez.

La idea es simple: la cantidad de energía necesaria para refutar una estupidez suele ser un orden de magnitud mayor que la necesaria para producirla.

Dicho menos elegante: decir una estupidez es barato. Desarmarla bien sale caro.

Y no hace falta irse a teorías conspirativas, discusiones de internet o gente defendiendo que la luna es un sánguche cósmico. En desarrollo de software pasa todo el tiempo. A veces con opiniones técnicas tiradas al aire. A veces con decisiones rápidas. A veces con atajos que parecen inofensivos. A veces con arquitectura decidida con más entusiasmo que evidencia.

“Esto no escala.”

“Hay que usar microservicios.”

“Ese bug es del frontend.”

“Refactorizar esto lleva dos días.”

“No hace falta revisar este cambio.”

“Probémoslo directo en producción, es chico.”

“Con cache lo resolvemos.”

Cada una de esas frases puede ser cierta en algún contexto. El problema es cuando entran a la conversación sin pagar entrada: sin evidencia, sin supuestos claros, sin trade-offs, sin hacerse cargo del costo de comprobarlas o revertirlas.

Porque en software una afirmación floja no siempre queda en una discusión. A veces se convierte en código. En arquitectura. En proceso. En una decisión que después el equipo tiene que mantener, explicar, refutar o desarmar.

Y ahí empieza el dolor.

La consecuencia rara vez tiene el tamaño de la decisión.

La frase fue barata. La prueba no.

Decir “esto no escala” lleva segundos. Demostrarlo bien es otra historia. Hay que mirar uso real, carga esperada, límites actuales, métricas, cuellos de botella, costos y alternativas. A veces resulta que sí: no escalaba. Perfecto. Pero otras veces descubrimos que el problema no era la escala, sino una query mal escrita, una integración lenta, una expectativa inventada o una mala estrategia de cache.

Decir “ese bug es del frontend” también es barato. Después alguien tiene que revisar requests, responses, contratos, logs, validaciones, feature flags, datos corruptos y quién sabe cuántas cosas más. Capaz era frontend. Capaz era backend. Capaz era un dato viejo. Capaz era una regla de negocio que nadie escribió.

Lo mismo pasa con “refactorizar esto es fácil”. Suena razonable hasta que aparecen dependencias ocultas, comportamientos no documentados, tests inexistentes y casos borde que nadie recuerda.

La frase inicial fue barata.

La investigación no.

Ese es el punto que muchas veces se pierde: cuando alguien tira una afirmación técnica fuerte sin evidencia, no está opinando gratis.

Está transfiriendo al resto el costo de pensar.

Cuando la frase se convierte en decisión

El problema se vuelve más serio cuando esa frase liviana deja de ser una frase y se convierte en una decisión técnica.

“Mergeemos directo a main, total somos pocos.”

“Que salga de latest, después taggeamos.”

“No hace falta revisar el código, el cambio es simple.”

“¿Hace falta documentar las pruebas? Si ya lo vimos.”

“Automatizar lleva mucho tiempo.”

“No hace falta documentar esta decisión, conversemos.”

Nada de eso suena escandaloso en el momento. Muchas veces suena práctico. Rápido. Sensato. Adaptado al contexto. Y puede serlo, si hay conciencia del riesgo y si todas las partes involucradas saben qué están aceptando.

En otro post hablé de esa frase tan cómoda que aparece en muchos equipos: “después lo acomodamos”. Ahí el foco estaba puesto en la deuda técnica que se toma, se minimiza y después queda dando vueltas como si no tuviera costo.

Acá quiero mirar otra capa del mismo problema: la asimetría.

Lo poco que cuesta tomar una decisión liviana y lo mucho que cuesta después explicarla, comprobarla, revertirla o vivir con sus consecuencias:

• Commitear directo a main puede ahorrar minutos hoy y romper la trazabilidad mañana.
• Salir de latest en lugar de salir de un tag o release puede parecer más simple hasta que necesitás saber exactamente qué versión está corriendo, reproducir un problema, hacer rollback o auditar qué se desplegó.
• No revisar código antes de producción puede acelerar una entrega, pero también elimina una conversación barata que podía evitar una corrección cara.
• No dejar evidencia de pruebas parece menor hasta que algo falla y la pregunta es: “¿esto se probó?”.
• No automatizar pruebas puede tener sentido al principio, pero si cada cambio importante depende de memoria, cuidado manual y fe, el costo no desapareció: quedó distribuido en cada entrega futura.
• Y no documentar decisiones técnicas suele justificarse con una frase clásica: “es obvio”.

Muchas cosas son obvias el día que las decidimos. El problema es que el software no se mantiene el día que lo decidimos. Se mantiene meses después, con otra urgencia, otra persona, otro contexto y bastante menos memoria.

Ahí lo obvio deja de ser obvio.

Pasa a ser arqueología.

Lo rápido también diseña

A veces hablamos de arquitectura como si sólo fueran grandes decisiones: microservicios, eventos, capas, bases de datos, patrones, infraestructura.

Pero muchas veces la arquitectura real se va formando con decisiones pequeñas que nadie trató como arquitectónicas.

Un deploy sin rollback claro.

Una API que cambia sin compatibilidad hacia atrás.

Una dependencia nueva que nadie evaluó demasiado.

Un flujo crítico sin pruebas automatizadas.

Una configuración productiva tocada a mano.

Un “por ahora” que nadie volvió a revisar.

Una decisión aislada puede parecer menor. El problema es que el sistema no vive las decisiones de forma aislada. Las acumula. Las combina. Las arrastra.

Y cuando alguien intenta cuestionarlas meses después, el costo de refutación es enorme. Ya no alcanza con decir “creo que esto está mal”. Hay que demostrar impacto, mapear dependencias, diseñar una alternativa, migrar sin romper, sostener compatibilidad y explicar por qué algo que parecía práctico tal vez estaba dejando complejidad escondida.

La decisión fue rápida. El “después” no.

Lo barato lo paga otro

Este es el punto incómodo: muchas veces lo barato no es barato. Simplemente lo paga otra persona, más tarde y con menos contexto.

Lo paga quien entra al equipo y tiene que entender por qué no hay tags claros. Lo paga quien investiga un incidente sin evidencia de pruebas. Lo paga quien intenta reproducir un bug y no sabe qué versión exacta está en producción. Lo paga quien modifica una parte del sistema y descubre que no había tests para los caminos importantes. Lo paga quien revisa una decisión técnica y no encuentra un ADR, una nota, un ticket, un comentario, nada.

Lo paga quien mantiene.

Y mantener software no es sólo arreglar cosas rotas. Es convivir con decisiones pasadas. Algunas buenas, otras malas, muchas razonables en su contexto, pero todas más difíciles de evaluar cuando no dejaron rastro.

Por eso el problema no es tomar decisiones rápidas. A veces hay que tomarlas. El problema es tomarlas como si la velocidad no tuviera consecuencias. Como si ahorrarnos diez minutos hoy no pudiera costarle tres días a alguien dentro de seis meses.

El costo no desaparece porque no lo miremos.

Sólo cambia de dueño.

No hace falta burocracia. Hace falta evidencia.

Cuidado con irnos al otro extremo. No todo cambio necesita un comité. No toda decisión técnica merece un documento de diez páginas. No cada línea de código necesita tres aprobaciones, un acta firmada y una ceremonia con velas.

Eso también es bullshit, pero del otro lado.

La salida no es burocratizar la ingeniería. Es ajustar el nivel de evidencia al nivel de impacto.

Si el cambio es trivial, tal vez alcanza con una review rápida. Si afecta un flujo crítico, necesitamos pruebas más serias. Si cambia una API pública, pensemos compatibilidad. Si modifica una decisión técnica importante, dejemos escrito el contexto y los trade-offs. Si se despliega algo a producción, deberíamos poder saber qué versión salió, cómo volver atrás y qué evidencia tenemos de que funciona.

No es burocracia. Es higiene técnica.

Y frente al bullshit técnico, la respuesta no siempre tiene que ser discutir. A veces alcanza con pedir precisión.

Porque si una persona puede tirar una frase fuerte en cinco segundos y el resto tiene que gastar días desarmándola, el sistema está premiando al que habla barato y castigando al que intenta trabajar con evidencia.

Decir algo también debería tener costo

No se trata de no opinar, no decidir o no tomar atajos. Se trata de no hacer pasar liviandad por criterio.

Una afirmación técnica sin evidencia puede parecer inofensiva. Una decisión rápida puede parecer pragmática. Un atajo puede parecer sentido común.

Hasta que alguien tiene que desarmar todo eso.

Por eso, cada decisión técnica importante debería cargar con un mínimo de evidencia proporcional a su impacto: qué problema resuelve, qué riesgo acepta, qué alternativa descarta y qué señal nos diría que nos equivocamos.

Porque en software, decir algo puede ser muy barato.

Pero desarmarlo después puede ser un dolor. Fuerte.

¿Qué frase, atajo o decisión técnica viste entrar barata y salir carísima?

Te leo en los comentarios.

¡Hasta la próxima!