En el último programa de Cruce de cables (RNE) le conté a David Sierra lo que es el factor autobús, un término informático y un poco geek que mide cuántas personas clave podrían desaparecer de un proyecto antes de que todo empezara a desmoronarse. El programa puede escucharse aquí:
No hace falta que sea literalmente un autobús y un atropello: puede ser una jubilación, gente que se va de la empresa, bajas de larga duración o alguien se ha cansado de ser quien sabe cómo funciona todo un tinglado. La expresión la acuñó Michael McLay en 1994 cuando planteó en una lista de correo dedicada al lenguaje Python qué pasaría si Guido van Rossum, el creador de Python, fuera atropellado por un autobús. La pregunta de fondo era seria: ¿podría sobrevivir el proyecto si casi todo el conocimiento importante depende de una sola persona?
Cuanto más bajo es el «factor autobús» de un proyecto o empresa, peor para todos. Es como si solo hay un panadero en el pueblo, se muere y nadie más sabe cómo se hace el pan. Todo el mundo pierde.
Un estudio de 2016 analizó 133 proyectos populares alojados en los repositorios de internet y descubrió que el 65% tenía un factor de 2 o menos: en muchos casos bastaría con que desaparecieran una o dos personas clave para dejar partes importantes del proyecto en una situación comprometida.
¿Qué mide realmente el factor autobús?
Este «factor autobús» mide en realidad la fragilidad humana de un sistema técnico. Una empresa puede tener 200 programadores, pero si solo una persona sabe cómo recompilar el sistema de pagos, arrancar un mainframe antiguo o explicar por qué no hay que tocar una rutina escrita en 1987, esa parte del sistema tiene un factor autobús bajísimo.
El problema no siempre es el código, que muchas veces funciona perfectamente. El riesgo está alrededor: muchas veces hay documentación incompleta, configuraciones raras, scripts que nadie entiende, contraseñas heredadas, carpetas con títulos peliagudos como «NO BORRAR»… En definitiva, un conocimiento transmitido «de generación a generación» durante años, pero poco formalmente, por decir algo.
¿Por qué afecta especialmente a bancos, administraciones, aviones o incluso a la NASA?
El hecho cierto es que muchos sistemas importantes siguen dependiendo de tecnología antigua que funciona demasiado bien como para tirarla y está demasiado integrada en el funcionamiento del día a día como para cambiarla alegremente.
En banca, COBOL sigue siendo el ejemplo clásico. Hace una década se estimaba que había miles de millones de dólares de actividad comercial a través de software escrito en COBOL: cuentas, tarjetas, cajeros automáticos, hipotecas, compensación de cheques y préstamos. El problema no es que COBOL sea malo, sino que muchas personas que lo dominan ya se han jubilado o están cerca.
En las administraciones públicas ocurre algo parecido. Muchos sistemas críticos tienen décadas de antiguedad y cuestan millones al año solo en mantenimiento y operaciones. Costaría demasiado actualizarlos y cambiarlos por algo más moderno.
Las reservas aéreas también dependen de mainframes muy especializados. Y en ciencia e ingeniería, Fortran sigue vivo en simulaciones, modelos y software que ha funciona bien durante décadas.
La NASA, por ejemplo, ha modernizado a veces código Fortran 77 porque muchas veces es mejor que reescribirlo desde cero. También han llamado a veces a ingenieros jubilados para explicarle a los jovenzuelos cómo se desarrolló cierto software o cierto componente hardware de alguna sonda espacial antiquísima.
Relacionados:
- La historia del lenguaje COBOL
- Un mainframe IBM 1401 de 1959 compilando Fortran
- Cómo la NASA diseñó el hardware y software que se «autorreparaba» en las naves y sondas de los 60 y 70
- WinWorld: un museo del software antiguo con todo tipo de programas y sistemas antiguos para descargar y disfrutar en comunidad
- El código fuente de MS-DOS y Word, al alcance del público en el Museo de Historia de la Computación
