¿Qué lenguaje de programación usan las sondas Voyager en 2026?
Las sondas Voyager 1 y Voyager 2 siguen operando con software escrito principalmente en Fortran 77 y lenguaje ensamblador, tecnologías de los años 70 que hoy resultan casi imposibles de encontrar en el mercado laboral tecnológico.
La NASA mantiene activo este código porque las sondas, lanzadas en 1977, continúan enviando datos científicos desde el espacio interestelar. El hardware original cuenta con apenas 8 KB de memoria por módulo, una cifra que hoy parece ridícula pero que ha permitido una de las misiones más longevas de la historia espacial.
¿Cuántos ingenieros pueden mantener este código legacy?
No existe una cifra oficial pública, pero las fuentes coinciden en que se trata de un grupo muy reducido de especialistas. El último ingeniero original de la misión estaba cerca de jubilarse hace años, lo que obligó a la NASA/JPL a buscar relevo externo.
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidadEl problema no es solo la escasez de talento: la documentación original está dispersa, con manuales en archivos no digitalizados, sótanos y garajes. Parte del conocimiento técnico solo existe en la memoria de veteranos de la misión, creando un riesgo sistémico de pérdida de información crítica.
¿Qué desafíos técnicos han enfrentado recientemente?
En episodios recientes de mantenimiento, la NASA detectó que aproximadamente un 3% de la memoria de Voyager 1 estaba dañada. Esto obligó al equipo a reprogramar comandos para evitar las zonas afectadas, trabajando con márgenes mínimos de error.
El desafío se agrava porque no existe un modelo físico de prueba en tierra equivalente a la sonda real. La NASA depende de simuladores del JPL, pero cada actualización conlleva el riesgo de perder comunicación permanentemente con una nave que está a miles de millones de kilómetros.
¿Por qué la documentación es infraestructura crítica?
El caso Voyager demuestra que la documentación no es un "extra" opcional: es infraestructura operativa. Después de casi 50 años, los manuales técnicos, simuladores y registros de decisiones son la diferencia entre recuperar un sistema o perderlo para siempre.
Las reglas de la NASA para escribir código en sistemas críticos priorizan simplicidad, límites fijos en bucles, mínima complejidad y control estricto del uso de memoria. Estas prácticas, documentadas desde hace décadas, siguen siendo relevantes para cualquier equipo que construya software de misión crítica.
¿Qué significa esto para tu startup?
Si diriges una startup tecnológica, el caso Voyager ofrece lecciones prácticas sobre gestión de deuda técnica y preservación del conocimiento. Tu producto puede no viajar al espacio interestelar, pero los principios de ingeniería sostenible son universales.
Acción 1: Documenta decisiones de arquitectura (ADRs)
- Crea registros de decisiones arquitectónicas que expliquen el "por qué", no solo el "qué"
- Mantén diagramas vivos y actualizados con cada cambio significativo
- Registra trade-offs y alternativas descartadas para contexto futuro
Acción 2: Reduce el bus factor
- Identifica componentes donde "solo una persona sabe cómo funciona"
- Implementa revisiones de código obligatorias en módulos críticos
- Usa pair programming rotativo para distribuir conocimiento
- Documenta runbooks de operaciones y recuperación de incidentes
Acción 3: Trata la deuda técnica como presupuesto
- Clasifica la deuda por impacto, urgencia y coste de no hacer nada
- Asigna un propietario y fecha de revisión para cada ítem
- Reserva capacidad del sprint para refactorización (15-20% recomendado)
Acción 4: Diseña para fallos y cambios
- Evita reescrituras totales salvo justificación extrema
- Moderniza por capas, aislando componentes legacy
- Automatiza pruebas y despliegues para reducir dependencia del conocimiento tribal
Lecciones de la NASA para founders hispanohablantes
En el ecosistema startup de LATAM y España, donde los equipos suelen ser más pequeños y los recursos más limitados, la gestión del conocimiento es aún más crítica. No puedes permitirte perder a tu único desarrollador senior sin documentación adecuada.
La deuda técnica no desaparece; se capitaliza. Los atajos que tomas hoy para mover rápido se convierten en lastre mañana. Voyager lleva casi 50 años operando porque la NASA trató la documentación y el mantenimiento como prioridades desde el día uno, no como tareas secundarias.
Si tu producto tiene horizonte de 10+ años, diseña desde el inicio para que el conocimiento no se pierda en 2. Eso significa documentación viva, propietarios claros de componentes, y procesos que sobrevivan a la rotación natural de talento.
Fuentes
- SpaceDaily - NASA Voyager Code Maintenance (fuente original)
- Xataka - Rescate de Voyager 1
- Genbeta - Lenguaje de programación de la NASA
- CampusMVP - Reglas de la NASA para código
- Wikipedia - Misión Voyager
👥 ¿Quieres ir más allá de la noticia?
En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.
👥 Unirme a la comunidad
