No aceptamos consejos de quienes no son desarrolladores

La astrofísica del software

06.01.2026, Por Stephan Schwab

Cuando decisiones críticas sobre desarrollo de software son moldeadas por quienes nunca han escrito código de producción, las organizaciones pagan un impuesto recurrente: proyectos fallidos, talento perdido, y desarrolladores que aprenden el nuevo vocabulario del framework mientras bromean sobre ello en el estacionamiento. Las organizaciones más efectivas aseguran que las decisiones técnicas estén informadas por genuina experiencia técnica.

La escena que lo dice todo

Hay un momento memorable en la película Armageddon de 1998 donde militares y científicos de la NASA debaten cómo detener un asteroide que destruiría la Tierra. Un general insiste en que los asesores científicos del presidente creen que una explosión nuclear podría cambiar la trayectoria del asteroide. El Dr. Ronald Quincy, un científico británico de la NASA presentado como “probablemente el hombre más inteligente del planeta”, ofrece una respuesta devastadora:

“Conozco al principal asesor científico del presidente. Estudiamos juntos en el MIT. Y en una situación como esta, realmente no quieres seguir el consejo de un hombre que sacó un aprobado raspado en astrofísica.”

La escena resuena porque captura algo que entendemos instintivamente: ante desafíos técnicos complejos, las personas que realmente entienden el dominio deberían guiar el enfoque. Una solución nuclear puede sonar decisiva, pero sin entender la mecánica orbital y la física, podría empeorar las cosas catastróficamente.

Las organizaciones de software enfrentan esta dinámica constantemente. Y demasiado a menudo, eligen el equivalente de la opción nuclear.

La sala de conferencias donde el código va a morir

Imagina una escena familiar: una sala de reuniones donde se toman decisiones sobre arquitectura de software. Alrededor de la mesa están sentados ejecutivos, gerentes de proyecto, y quizás un consultor de una firma prestigiosa. Los desarrolladores — las personas que realmente construirán el sistema — están ausentes, en minoría, o hablan al final.

Alguien sugiere reescribir el sistema en un framework que leyó en Harvard Business Review. Otro propone blockchain porque la empresa del compañero de golf hizo algo con blockchain. Un tercero insiste en una solución de un proveedor porque la presentación de ventas fue impresionante.

Los desarrolladores intercambian miradas. Saben que estos enfoques crearán problemas. Pero están en minoría, tienen menor rango, o simplemente no les preguntan.

Por qué este patrón persiste

Sería fácil culpar a la arrogancia, pero el patrón tiene raíces estructurales.

La jerarquía supera a la experiencia. La antigüedad en el organigrama confiere autoridad en todos los dominios. Se asume que la persona que destaca en finanzas tiene opiniones válidas sobre arquitectura de software. Pero un brillante ejecutivo de marketing no se convierte en cirujano calificado por subir en la escalera corporativa.

La abstracción crea confianza. El software es invisible. No puedes tocarlo ni ver su estructura interna. Esto lo hace parecer más simple de lo que es. “Es solo código, ¿qué tan difícil puede ser?” Nadie mira un rascacielos y dice: “Es solo acero y concreto, ¿qué tan difícil puede ser?”

Los consultores hablan el lenguaje del poder. Los consultores externos tienen éxito diciéndoles a los ejecutivos lo que quieren escuchar en lenguaje que suena estratégico. La simplificación confiada del consultor gana contra la cualificación cuidadosa del desarrollador.

El framework que lo arreglará todo

Quizás ningún patrón ilustra mejor el problema que los frameworks de gestión impuestos a los equipos de desarrollo. Una nueva metodología llega — completa con certificaciones, consultores y vocabulario fresco — prometiendo resolver todos los problemas de entrega. Los desarrolladores son enviados a capacitación. Nuevos rituales son obligatorios. Los dashboards se configuran.

Y entonces: nada cambia.

Los desarrolladores aprenden la terminología. Asisten a las ceremonias requeridas. Actualizan los elementos de trabajo con las etiquetas esperadas. Para los ejecutivos, todo parece transformado. La organización “se volvió Agile” o adoptó “SAFe”.

Pero en el estacionamiento, ocurre una conversación diferente. Los desarrolladores bromean sobre todo el teatro. Traducen su trabajo real a lenguaje-de-framework para las reuniones de estado, luego lo traducen de vuelta para hacer las cosas. El framework se convierte en un impuesto a la productividad — gastos generales que gestionar en lugar de una herramienta que ayuda.

Esto no es cinismo. Es adaptación. Cuando las personas que entienden el trabajo no son consultadas sobre cómo organizar el trabajo, el resultado inevitable es una brecha entre el proceso oficial y el real. El proceso real continúa en cualquier forma que funcione. El proceso oficial se convierte en arte performativo.

La tragedia es que muchos frameworks contienen ideas genuinamente útiles. Pero impuestos desde arriba, sin input de quienes entienden el trabajo, incluso las buenas ideas se convierten en mandatos resentidos.

El costo de ignorar la experiencia

Las organizaciones que consistentemente anulan la experiencia de los desarrolladores pagan un impuesto recurrente:

Los proyectos fracasan. Cuando las decisiones técnicas son tomadas por personas no técnicas, los sistemas a menudo no funcionan como se prometió. El asteroide no es destruido; se rompe en fragmentos que causan aún más daño.

Los buenos desarrolladores se van. Los profesionales talentosos tienen opciones. Cuando su experiencia es ignorada consistentemente, encuentran organizaciones que valoran lo que saben.

La deuda técnica se acumula. La solución rápida que parecía razonable en una sala de conferencias se convierte en un lastre permanente para la productividad.

La innovación se estanca. Cuando los desarrolladores aprenden que su experiencia no es valorada, dejan de ofrecerla. Implementan lo que les dicen, aunque saben que no funcionará.

Cómo suena la experiencia genuina

Los desarrolladores no intentan ser difíciles cuando plantean preocupaciones. Intentan prevenir desastres.

Cuando un desarrollador dice “ese cronograma es poco realista”, está aplicando años de experiencia para reconocer que ciertas cosas toman cierta cantidad de tiempo. Cuando cuestiona una elección tecnológica, está considerando factores que no serán visibles hasta meses dentro del proyecto. Cuando solicita tiempo para refactorización, está identificando trabajo necesario que se hará proactiva y económicamente, o reactiva y costosamente.

Las credenciales que importan en software no son títulos o certificaciones. Son haber construido cosas que funcionaron en producción. Haber mantenido sistemas y sentido cómo los atajos de hoy se convierten en las emergencias de mañana. Haber lanzado proyectos que no funcionaron y aprendido qué evitar.

Crear espacio para el juicio técnico

Las organizaciones que construyen software exitoso crean estructuras donde la experiencia técnica informa las decisiones técnicas.

Incluir a los desarrolladores en las decisiones. Cuando una elección tiene implicaciones técnicas — lo que significa la mayoría de las elecciones sobre software — los desarrolladores deberían estar en la sala, no recibiendo decisiones después del hecho.

Ponderar la experiencia apropiadamente. Cuando el tema es astrofísica, la opinión del astrofísico importa más. Cuando el tema es arquitectura de código, las opiniones de los desarrolladores deberían tener peso decisivo.

Distinguir entre qué y cómo. El liderazgo empresarial decide apropiadamente qué problemas resolver. Los profesionales técnicos deciden apropiadamente cómo resolverlos. La confusión entre estos dominios es donde ocurre la disfunción.

Nada de esto significa que los no-desarrolladores no tengan rol. La experiencia empresarial, el conocimiento del dominio y la visión estratégica son inputs esenciales. Pero estos inputs deberían informar los enfoques técnicos, no dictarlos. Un CEO podría decir apropiadamente: “Necesitamos manejar diez veces nuestro tráfico actual.” Un CEO no debería entonces decir: “Por lo tanto usen microservicios y Kubernetes” — a menos que tenga el trasfondo técnico para hacer esa recomendación.

La pregunta que vale la pena hacer

En Armageddon, el enfoque de los científicos de la NASA prevalece. La cruda solución nuclear da paso a un plan que considera la física real. La misión tiene éxito porque la experiencia fue valorada.

La próxima vez que estés en una reunión donde se toman decisiones sobre software, mira alrededor de la sala. ¿Quién está hablando? ¿A quién se escucha? ¿Las personas con experiencia relevante están moldeando la discusión, o están siendo anuladas por personas cuyas credenciales están en otros dominios?

Si eres un líder tomando decisiones sobre software, considera: ¿aceptarías un plan de cirugía diseñado por tu abogado? ¿Una estrategia legal ideada por tu contador? La experiencia técnica de los desarrolladores de software merece el mismo respeto que darías a cualquier otro dominio profesional.

No aceptamos consejos del tipo que sacó un aprobado raspado en astrofísica. Quizás es hora de aplicar la misma lógica al desarrollo de software.