28.12.2025, Por Stephan Schwab
El 20 de diciembre de 1995, una tripulación altamente entrenada estrelló un avión en perfecto estado contra una ladera colombiana. Siguieron su plan con precisión. Confiaron en sus instrumentos. Murieron de todos modos. En el desarrollo de software, llamamos a esto "mantenernos en el rumbo" — y destruye proyectos tan seguramente como destruyó el Vuelo 965.
Era cinco días antes de Navidad. Ciento cincuenta y nueve personas volaban a casa con sus familias. Algunos tenían regalos en los compartimentos superiores. Algunos ya pensaban en las comidas que compartirían, los rostros que verían, los abrazos que los esperaban en la puerta de llegada en Cali.
Nunca llegaron.
El Vuelo 965 de American Airlines era un viaje rutinario de Miami a Cali, Colombia. El Boeing 757 estaba en perfecto estado mecánico. El capitán tenía más de trece mil horas de vuelo. El primer oficial era experimentado y competente. El clima estaba despejado en altura.
Nada estaba mal — excepto que todo estaba a punto de salir catastróficamente mal.
Durante la aproximación, el control de tráfico aéreo ofreció un atajo. La tripulación aceptó. Un simple cambio al plan. Comenzaron a reprogramar el computador de gestión de vuelo, ingresando un nuevo punto de referencia: “R” de Rozo, la radiobaliza cerca de Cali.
Pero la letra R mostró primero una baliza diferente. Una cerca de Bogotá. A ciento treinta kilómetros de distancia. En la dirección equivocada.
La tripulación la seleccionó. El avión, obediente como siempre, viró a la izquierda y comenzó a volar alejándose de Cali, directamente hacia los Andes.
No lo notaron. Los instrumentos les mostraban que estaban en curso — el curso que el computador seguía, no el curso que habían pretendido. Los pilotos confiaron en el plan. Ellos mismos lo habían ingresado. ¿Por qué dudarían de él?
Afuera de las ventanas, invisibles en la oscuridad, las montañas se elevaban.
A las 9:41 PM, el Sistema de Advertencia de Proximidad al Suelo cobró vida gritando: “TERRAIN, TERRAIN. PULL UP. PULL UP.”
El capitán reaccionó instantáneamente. Empujó las palancas de potencia hacia adelante. Tiró de la nariz hacia arriba con fuerza. El avión respondió — estaba haciendo todo lo posible para ascender, escapar, vivir.
Pero alguien había dejado los frenos aerodinámicos extendidos desde el descenso. Esos paneles en las alas, diseñados para desacelerar el avión, estaban robando la sustentación que desesperadamente necesitaban. La tripulación no lo notó. Estaban concentrados en el ascenso. Estaban siguiendo el procedimiento de recuperación.
Seis segundos después, el Vuelo 965 impactó contra el costado de El Diluvio — una cresta que se eleva a casi tres mil metros.
Cuatro pasajeros sobrevivieron, lanzados fuera de los escombros. Ciento cincuenta y nueve personas — padres, hijos, colegas, amigos — no.
Les cuento esta historia no para recrearme en la tragedia sino porque observo cómo las organizaciones vuelan hacia montañas todos los días.
No montañas literales. Peor, en cierto modo — invisibles. Deuda técnica sobre la que desarrolladores experimentados han advertido durante años. Decisiones arquitectónicas impuestas por consultores que se fueron antes de que llegaran las consecuencias. Hojas de ruta dictadas por personas que nunca han entregado software, obligando a los equipos a construir lo que no se puede construir en el tiempo que no existe.
La tripulación del Vuelo 965 no era estúpida. No era descuidada. Eran profesionales altamente entrenados operando equipos costosos según procedimientos documentados. Siguieron el plan.
Y el plan los estrelló contra una montaña.
Los planes son seductores. Ofrecen certeza en un mundo incierto. Nos permiten decirles a los interesados cuándo terminaremos. Crean la ilusión de que entendemos lo que estamos construyendo, cuánto tiempo tomará y qué depara el futuro.
Pero los planes no son la realidad. Son nuestra mejor suposición sobre la realidad en un momento dado — usualmente el momento en que menos sabíamos sobre lo que estábamos intentando.
La tripulación del Vuelo 965 tenía un plan. Estaba registrado con el control de tráfico aéreo. Estaba programado en el computador. Consideraba combustible, tiempo, puntos de referencia y restricciones de altitud. Era un buen plan.
Simplemente no consideraba una sola pulsación de tecla equivocada.
Aquí está la verdad incómoda que todo ejecutivo, todo gerente de programa, todo entusiasta de los diagramas de Gantt necesita entender:
La realidad no negocia.
A la montaña no le importaba que la tripulación tuviera un plan. A la montaña no le importaba que el computador les mostrara que estaban en curso. A la montaña no le importaban las trece mil horas de experiencia del capitán ni el historial de seguridad de la aerolínea ni los planes navideños de los pasajeros.
La montaña simplemente estaba ahí. Y cuando el camino del avión se intersectó con la ubicación de la montaña, la montaña ganó. Siempre gana.
La complejidad técnica es una montaña. Las restricciones arquitectónicas son una montaña. Las leyes de la física que gobiernan cómo se comportan los sistemas de software bajo carga — esas son montañas. Cada vez que la dirección anula el juicio de los desarrolladores con una directiva de consultores o un mandato de la sala de juntas, están programando un nuevo curso. A veces ese curso conduce hacia un terreno que nadie puede ver desde la suite ejecutiva.
El sistema de advertencia del Vuelo 965 dio a la tripulación una alerta. Era fuerte. Era inequívoca. Era aterradora por diseño.
Tuvieron seis segundos. No fue suficiente — en parte porque los frenos aerodinámicos robaron su tasa de ascenso, pero también en parte porque la advertencia llegó demasiado tarde. La vieja tecnología del sistema no podía ver hacia adelante; solo podía detectar el suelo acercándose desde abajo.
Tu organización también tiene sistemas de advertencia. Desarrolladores senior diciendo “esta arquitectura no escalará”. El líder del equipo advirtiendo que el cronograma es una fantasía. Ingenieros explicando — otra vez — por qué el enfoque mandatado por la costosa firma de consultoría no puede funcionar. Voces experimentadas, descartadas como “resistentes al cambio” o “no son jugadores de equipo”, porque se niegan a pretender que la montaña no está ahí.
Esas son tus advertencias de terreno. Te están gritando ahora mismo.
¿Estás escuchando? ¿O estás siguiendo el plan que alguien fuera de tu cabina programó para ti?
La investigación del Vuelo 965 cambió la aviación. La industria desarrolló Sistemas Mejorados de Advertencia de Proximidad al Suelo — EGPWS — que usan GPS y bases de datos de terreno para ver montañas adelante, no solo abajo. Las aerolíneas revisaron sus procedimientos para programar computadores de vuelo. El entrenamiento enfatizó la conciencia situacional sobre la confianza ciega en la automatización.
Ciento cincuenta y nueve personas murieron, y una industria aprendió.
Pero no toda organización aprende del desastre. Algunas responden comprando soluciones de las mismas personas que les vendieron el problema.
Hay otra forma en que las organizaciones se estrellan contra montañas: compran marcos de gestión que prometen “arreglar” a los desarrolladores. Hacerlos predecibles. Hacerlos fluir suavemente a través de un proceso como widgets en una línea de ensamblaje. La presentación de ventas siempre incluye la palabra “aprendizaje” — mejora continua, ciclos de retroalimentación, adaptación.
Pero luego viene la implementación.
El framework es instalado por personas que nunca han escrito código de producción. Los entrenadores se van. Y lo que queda es un sistema que castiga el aprendizaje. Volver atrás es fracaso. Refactorizar es desperdicio. Cambiar de dirección después de descubrir nueva información es desviación del plan. Todo el aparato está diseñado alrededor de la ilusión de que el trabajo fluye hacia adelante y nunca regresa — que puedes saber todo al principio y simplemente ejecutar.
Esto contradice todo lo que sabemos sobre construir software. El Desarrollo Guiado por Pruebas funciona precisamente porque vuelves atrás. Escribes una prueba que falla, la haces pasar, refactorizas. Rojo, verde, refactorizar. El ciclo es el aprendizaje. Cada iteración te enseña algo sobre el problema que no podrías haber sabido antes de empezar.
Pero el framework fue vendido con la promesa de que la dirección finalmente tendría visibilidad y control. Que los desarrolladores se convertirían en recursos predecibles. Que las estimaciones se convertirían en compromisos y los compromisos en fechas de entrega. Volver atrás no era parte de la presentación de ventas.
Así que cuando los desarrolladores intentan refactorizar — intentan aprender, intentan mejorar — se les dice que paren. El hito está fijado. El cronograma está aprobado. Los recursos están asignados. No hay tiempo para aprender. Solo hay tiempo para ejecutar. Así es como las organizaciones destruyen la motivación intrínseca de sus desarrolladores — tratando el pensamiento como un defecto en lugar de una característica.
Y el avión desciende, confiado y controlado, hacia una montaña que los tableros del framework no muestran.
Hay un peligro más sutil que estrellarse contra una montaña. A veces las organizaciones crean políticas tan rígidas que incluso cuando los pilotos pueden ver la pista claramente, se les prohíbe aterrizar.
El 16 de octubre de 2023, el vuelo LH458 de Lufthansa — un Airbus A350 desde Múnich — se aproximó al Aeropuerto Internacional de San Francisco. El clima estaba despejado. La pista era visible. El avión funcionaba perfectamente. La tripulación era experimentada y alerta.
Pero SFO estaba operando solo con aproximaciones visuales esa noche. Y la política corporativa de Lufthansa, instituida después del aterrador casi-desastre de Air Canada en 2017 donde una tripulación fatigada casi aterriza en una pista de rodaje llena de aviones, prohibía a sus pilotos aceptar aproximaciones visuales de noche. La política requería una aproximación por instrumentos — ILS o guiada por satélite — sin importar las condiciones.
El ILS estaba apagado. La tripulación podía ver la pista. No se les permitía aterrizar en ella.
Así que declararon emergencia de combustible y se desviaron a Oakland. Los pasajeros fueron trasladados en autobús de regreso a San Francisco. Nadie murió. Pero un avión lleno de personas pasó horas en un autobús porque la política corporativa se había vuelto más importante que el juicio de los pilotos.
Esto es lo que sucede cuando las organizaciones responden al fracaso eliminando la discreción. Después de que Air Canada 759 casi matara a más de mil personas al confundir una pista de rodaje con una pista de aterrizaje durante una aproximación visual, la respuesta de Lufthansa fue racional: prohibir completamente las aproximaciones visuales nocturnas. Eliminar la posibilidad del error humano eliminando el juicio humano.
Pero las políticas no pueden anticipar cada situación. La tripulación de LH458 no estaba fatigada. No estaba confundida. Podían ver exactamente a dónde necesitaban ir. La política, diseñada para prevenir un tipo de falla, creó un tipo diferente de absurdo.
En las organizaciones de software, esto sucede constantemente. Un proyecto fracasa porque los desarrolladores tomaron decisiones autónomas que la dirección no entendió. ¿La respuesta? Eliminar la autonomía de los desarrolladores. Instituir procesos de aprobación. Requerir autorizaciones. Exigir que todas las decisiones técnicas fluyan a través de gerentes no técnicos que han sido entrenados por vendedores de frameworks para desconfiar de las mismas personas que construyen el software.
Los desarrolladores pueden ver la pista. Saben cómo aterrizar. Pero no se les permite. El método se ha convertido en el amo. La política existe para proteger contra una falla que no está sucediendo, mientras crea nuevas fallas que nadie anticipó.
Y a veces la empresa no se desvía a Oakland. A veces se queda sin combustible. Recuperar tu organización significa confiar en las personas que realmente vuelan el avión.
¿Cuántos proyectos deben morir antes de que tu organización aprenda? ¿Cuántos millones deben cancelarse? ¿Cuántos desarrolladores talentosos deben quemarse y marcharse, sus advertencias vindicadas demasiado tarde? ¿Cuántas empresas deben morir — realmente morir, puertas cerradas, todos se fueron — antes de que el liderazgo entienda que las personas en la cabina podrían saber más sobre volar que las personas en la sala de juntas?
Cada día, los líderes enfrentan una elección: seguir el plan o seguir la realidad.
Seguir el plan es cómodo. Significa que el reporte trimestral se ve predecible. Significa que nadie tiene que explicar por qué cambió la hoja de ruta. Significa que el costoso marco de gestión que compraste está funcionando como se anunció.
Seguir la realidad es difícil. Significa admitir incertidumbre. Significa decirles la verdad a los interesados. Significa confiar en las personas más cercanas al trabajo para que te digan lo que realmente está sucediendo — y creerles cuando contradice tu plan cuidadosamente construido.
La tripulación del Vuelo 965 siguió su plan. Confiaron en su computador. Descendieron con confianza a través de la oscuridad, creyendo que sabían dónde estaban.
Estaban equivocados. Y porque estaban equivocados, ciento cincuenta y nueve personas nunca vieron la Navidad.
En algún lugar de tu organización ahora mismo, un desarrollador experimentado está planteando una preocupación. Está diciendo que el cronograma es imposible. Está explicando por qué la arquitectura mandatada desde arriba no puede soportar las funcionalidades planificadas. Está señalando que el enfoque impuesto por consultores externos contradice todo lo que sabe sobre construir software que realmente funciona.
Él es tu advertencia de terreno. Te está gritando.
¿Qué harás?
¿Seguirás el plan que fue entregado desde arriba? ¿Te mantendrás en curso, forzando a tu tripulación experimentada a ejecutar una ruta de vuelo que saben que está mal, descartando sus advertencias como negatividad o resistencia al cambio?
¿O confiarás en las personas que realmente vuelan el avión — y los dejarás ver la montaña antes de que mate a todos a bordo?
Ciento cincuenta y nueve personas murieron cinco días antes de Navidad porque profesionales entrenados confiaron más en su plan que en la realidad.
La montaña sigue ahí. Siempre está ahí.
La única pregunta es si la verás a tiempo.
Hablemos de tu situación real. ¿Quieres acelerar la entrega, quitar bloqueos técnicos o validar si una idea merece más inversión? Reserva una conversación breve (20 min): escucho tu contexto, te doy 1–2 recomendaciones prácticas sin compromiso ni discurso comercial. Si encaja, seguimos; si no, te llevas claridad. Confidencial y directo.
¿Prefieres correo? Escríbeme: sns@caimito.net