Hay una pregunta que hago muchísimo cuando un equipo me muestra una solución:

¿Por qué lo hicieron así?

No la hago esperando una respuesta determinada ni porque crea que necesariamente existe una forma mejor. Quiero entender la decisión. Y una respuesta que aparece con bastante frecuencia es:

“Porque ya estaba hecho así.”

Ahí suelo detenerme. No porque esté necesariamente mal, sino porque dejamos de hablar de una decisión y empezamos a hablar de una herencia.

Toda decisión tuvo alguna vez un contexto

Detrás de prácticamente cualquier sistema existe una historia. Quizás había que lanzar rápido, el equipo era mucho más chico, determinada tecnología era la única disponible o había un cliente que necesitaba una solución urgente. Quizás simplemente alguien tomó una decisión razonable con la información que tenía.

El problema no es heredar decisiones. Es heredarlas sin heredar también las razones que llevaron a tomarlas. Porque el contexto puede haber cambiado completamente mientras la solución permaneció igual.

La respuesta que me gustaría escuchar

Cuando pregunto por qué hacemos algo de determinada manera, no espero necesariamente una explicación técnica extensa. Una respuesta como esta me parece mucho más valiosa:

“Se decidió así por estas razones. Estas condiciones siguen siendo válidas. Y si alguna de ellas cambia, deberíamos revisarlo.”

Hay tres elementos muy importantes ahí:

  1. Razones: sabemos por qué se tomó la decisión.
  2. Supuestos: sabemos qué condiciones hacen que siga teniendo sentido.
  3. Disparadores: sabemos qué tendría que cambiar para volver a evaluarla.

Eso convierte una decisión heredada en una decisión que todavía podemos explicar.

Pero aparece otro problema.

¿Dónde guardamos esa explicación?

Las decisiones también necesitan memoria

Si la razón de una decisión solamente existe en la cabeza de quien la tomó, tarde o temprano vamos a perderla. La persona puede cambiar de equipo, asumir otro rol o irse de la empresa. Meses después alguien encontrará la solución, preguntará por qué funciona así y recibirá una respuesta perfectamente honesta:

“Porque ya estaba hecho así.”

Una herramienta sencilla para evitarlo son los Architecture Decision Records (ADRs). No necesitan ser documentos enormes. Para muchas decisiones puede alcanzar con registrar:

  • qué problema estábamos intentando resolver;
  • qué decisión tomamos;
  • qué alternativas evaluamos;
  • cuáles eran los principales supuestos;
  • y qué condiciones deberían llevarnos a revisar esa decisión.

En realidad, la respuesta que me gustaría escuchar de un equipo es prácticamente un ADR resumido:

Tomamos esta decisión por estas razones, bajo estos supuestos, y sabemos qué tendría que cambiar para revisarla.

Documentar decisiones no elimina las malas decisiones. Evita algo diferente: que perdamos el contexto de las buenas y de las malas.

Cómo preguntar también importa

Hay algo que aprendí con el tiempo: cuando la pregunta “¿por qué hicieron esto así?” viene de un CTO o de cualquier persona con una posición de liderazgo, puede no escucharse como curiosidad. Puede escucharse como una auditoría. Por eso importa tanto la intención como la forma de preguntar.

En lugar de:

“¿Por qué hiciste esto así?”

prefiero algo como:

“¿Qué problema había que resolver cuando se tomó esta decisión?”

Muchas veces también aclaro desde el principio:

“No estoy diciendo que haya que cambiarlo. Quiero entender por qué está así.”

Y, cuando es posible, prefiero que estas conversaciones ocurran con el equipo y no como un interrogatorio individual. El objetivo no es encontrar al responsable de una decisión. Es reconstruir el contexto que la hizo razonable —o descubrir que ya no lo es—.

Dar unos pasos hacia atrás

Cuando un equipo está desarrollando una funcionalidad suele estar naturalmente concentrado en resolver el problema que tiene adelante. Y eso es necesario. Pero muchas veces encuentro valor en retroceder algunos pasos y mirar el problema completo. Si estamos agregando una nueva condición a un proceso, por ejemplo, podemos simplemente agregar otro if.

El primer if puede ser exactamente la solución correcta. El segundo quizás sea una coincidencia. Pero cuando aparece el tercero, vale la pena preguntarnos si realmente estamos frente a excepciones o si descubrimos que aquello que codificamos como una regla debería ser un dato o una configuración.

También existe el error opuesto.

Intentar construir una abstracción genérica frente al primer if puede ser igual de costoso. Podemos terminar diseñando una plataforma para resolver problemas que nunca van a existir. Por eso no se trata de abstraer siempre. Se trata de reconocer cuándo el problema dejó de ser excepcional.

Cuestionar no significa cambiar

Esta distinción me parece fundamental. Cuando pregunto por qué algo funciona de determinada manera, no estoy diciendo que haya que modificarlo. Muchas veces cuestioné una solución, la analizamos y terminamos llegando exactamente a la misma conclusión:

está bien como está.

Eso es saludable.

Si funciona, no genera costos desproporcionados, no introduce riesgos relevantes y sigue respondiendo a las necesidades del negocio, cambiarlo puede ser una pésima utilización de recursos. El objetivo no es crear una cultura donde todo esté permanentemente en discusión. El objetivo es crear una cultura donde las decisiones puedan ser explicadas y cuestionadas cuando sea necesario.

En otro artículo desarrollé una pregunta relacionada: cómo determinar cuándo el costo de no cambiar empieza a superar al costo de hacerlo. Acá me interesa algo anterior a ese cálculo.

Que sepamos qué decisión estamos evaluando y por qué existe.

Reutilizar no significa diseñar todos los futuros posibles

Cuando les pregunto a los equipos si algo puede hacerse de manera más reutilizable, no estoy proponiendo diseñar una plataforma capaz de resolver todos los problemas que quizás aparezcan dentro de diez años. Eso sería otra forma de desperdicio. El objetivo es detectar cuándo ya tenemos información suficiente para saber que determinadas condiciones probablemente van a cambiar.

Hay una diferencia importante entre:

diseñar para todos los futuros posibles

y

no cerrarnos innecesariamente el futuro.

La segunda me interesa mucho más.

Una buena decisión tecnológica no tiene que anticipar todo lo que ocurrirá. Pero debería intentar evitar que una elección innecesariamente rígida convierta cada cambio futuro en una reconstrucción.

El liderazgo también tiene que poder ser cuestionado

Cuestionar tiene otra consecuencia: a veces uno está equivocado.

Me pasó muchas veces.

Llegar a una posición de liderazgo no significa que nuestras preguntas sean automáticamente mejores ni que tengamos que encontrar algo para modificar cada vez que revisamos una solución. Si después de discutirla el equipo demuestra que la decisión tiene sentido, hay una respuesta perfectamente válida:

“Tenés razón.”

Si queremos equipos capaces de cuestionar decisiones, el primero que tiene que estar dispuesto a ser cuestionado es quien lidera. De lo contrario no estamos creando pensamiento crítico. Estamos reemplazando una respuesta automática:

“Siempre se hizo así.”

por otra:

“Se hace así porque lo dijo el CTO.”

Y no mejoramos nada.

La IA puede hacer este problema todavía más importante

DORA lleva desde 2014 estudiando cómo las capacidades técnicas, los procesos y la cultura influyen en el desempeño de las organizaciones de software. Su State of AI-assisted Software Development 2025, basado en cerca de 5.000 profesionales tecnológicos, introduce una idea que me parece particularmente interesante: la IA funciona como un amplificador.

No necesariamente arregla el sistema en el que la incorporamos.

Amplifica lo que ya existe.

Según DORA, la adopción de IA entre profesionales de desarrollo alcanzó el 90% en 2025. La investigación encontró mejoras en throughput, pero también aumentos en la inestabilidad de entrega. Esto vuelve todavía más relevante la discusión sobre decisiones heredadas. Pensemos en una instrucción extremadamente común para una herramienta de desarrollo asistida por IA:

“Seguí los patrones existentes en este repositorio.”

Es una instrucción razonable.

Pero si nadie recuerda por qué existen esos patrones, acabamos de construir una herramienta extraordinariamente eficiente para reproducirlos. Una decisión que antes copiaban algunas personas ahora puede propagarse mucho más rápido. La IA puede acelerar buenas prácticas. También puede industrializar decisiones que nadie volvió a cuestionar.

Los sistemas fuertes no dependen de respuestas históricas

Una buena organización tecnológica no es aquella que eligió siempre correctamente.

Eso es imposible.

Es aquella que conserva la capacidad de explicar por qué tomó sus decisiones, reconocer los supuestos que las sostienen y revisarlas cuando esos supuestos dejan de ser válidos.

Por eso quizás el problema con:

“Siempre se hizo así”

no sea que la decisión sea vieja.

El problema es que perdimos el original y nos quedamos solamente con la copia. La próxima vez que alguien pregunte:

“¿Por qué hacemos esto así?”

me gustaría que pudiéramos responder:

“Se decidió así por estas razones. Estas condiciones siguen siendo válidas. Y si alguna cambia, lo revisamos.”

No necesitamos tener todas las respuestas. Pero sí deberíamos intentar conservar las razones detrás de nuestras decisiones. Porque construir una organización capaz de cambiar empieza por algo bastante sencillo:

seguir sabiendo por qué hacemos lo que hacemos.

Fuentes y lecturas