Siempre que algún software falla (el último en salir en todas las portadas es el fiasco en las votaciones demócratas en EEUU), sale la pregunta de cómo es posible que no seamos capaces de crear software sin errores cuando, con una tecnología mucho más precaria, pudimos llevar el hombre a la Luna.

En este post, Peter Wayner argumenta que, de hecho, la razón es muy sencilla: Programar hoy en día es mucho más difícil que hace 50 años. Y para convencernos propone los cinco argumentos que os resumo a continuación. Evidentemente, esta opinión busca ser controvertida (y lo es). Y cada uno de los argumentos que da se puede invertir fácilmente para defender lo contrario. Pero al mismo tiempo, creo que es una reflexión muy interesante y que vale la pena dedicar unos minutos a comprender su punto de vista. ¡Algo de razón tiene!.

Fijaros que según él problema no es el escribir el código que implementa la funcionalidad real del software sino todo lo que viene con ella. Que antes era casi nada y ahora es muchísimo. No es tanto que programar sea más difícil sino que crear software lo es. Veamos sus argumentos:

El código era más simple

Y cada línea era una sola instrucción. Coged cualquier archivo del código fuente del Apollo 11 y veréis que los archivos son todos pequeños y con muchos comentarios. En cambio, con los frameworks de hoy en día, una instrucción puede afectar a muchos componentes al mismo tiempo y a cada pieza de software se le piden muchísimas funcionalidades.

El hecho de que la computadora del Apollo sólo tuviera 36k de ROM para almacenar la versión compilada del software era la excusa perfecta para descartar cualquier petición de funcionalidad que no fuera realmente esencial.

Eso sí, había que escribir en ensamblador (algunos de vosotros a lo mejor no sabéis ni de qué hablo 🙂 ). Al principio parece más difícil de aprender pero ya os digo que, comparado con la oscura semántica de JavaScript, ¡es cosa de niños!

La seguridad no era un problema

Ahora todos los dispositivos están conectados a Internet lo que multiplica la probabilidad que nuestro software sea la diana de todo tipo de ataques. Y nos obliga a protegerlo, añadiendo más y más complejidad al código fuente (gestión de usuarios/passwords, tokens de APIs, inyección de código,…)

Cuando enviamos el hombre a la Luna no había Internet, ni nadie atacando los sistemas software del cohete.

Lo único importante era la funcionalidad

Los astronautas no se preocupaban del tipo de fuente. Ni de la combinación de colores. Ni del estilo de los botones. Lo único que querían era llegar vivos a casa. Mientras el software funcionara todo lo demás no importaba.

Hoy en día, la funcionalidad es casi lo de menos. Nos fijamos más en la parafernalia que en la utilidad. Y aunque los frameworks de hoy en día nos ayuden mucho a conseguir un software bonito, también nos imponen unos criterios de calidad de la interfaz que no podemos pasar por alto si queremos que alguien use nuestro software, aunque sea el qué mejor funcione.

Había menos piezas cambiantes

La complejidad de un software depende mucho del número de piezas que tenga. En el Apollo cada componente se encargaba de una sola cosa. Ahora cada componente tiene que hacer e interactuar con muchísimos otros componentes y librerías.

Por un lado te hacer la vida más fácil al proporcionar funcionalidad que puedes necesitar pero por otro lado generan una multitud de dependencias que son una fuente inagotable de problemas.

No hay abogados en la Luna

Había y hay abogados pero parece que el mundo del software está cada vez más judicializado. Y no hablo sólo de las guerras de patentes y licencias. Las “Terms and Conditions” para alquilar un servidor en la nube de Amazon son más de 20.000 palabras. Y lo mismo para cada web, servicio o API que quieras usar después.

Los programadores del Apollo no tuvieron que lidiar con nada de eso ni preocuparse por ninguna violación de servicios externos (y siendo un programa nacional aún menos). Otra razón para poder concentrarse en lo realmente importante.

¿Es o no hoy en día más difícil programar?

¿Qué os han parecido estos argumentos?. Yo creo que es obvio que hoy en día es más fácil empezar a programar. Y si lo que queremos es hacer una aplicación estándar, de hecho casi que no hace falta ni programar nada.

Pero si lo que tenemos que hacer es una aplicación software crítica creo que todos echamos de menos algunas de las “protecciones” y “simplificaciones” de las que se pudieron aprovechar los programadores del Apollo 11. Como siempre, la virtud está en el término medio. Como mínimo tened en mente la regla de Pareto y aseguraros que el añadir a vuestro programa una librería externa aporta más que los problemas de mantenimiento que os va a ocasionar.

Imagen gracias a Jukan Tateisi on Unsplash