Con la democratización de la información por internet, la creación de servicios en la nube que te lo dan casi todo hecho y la llegada de la inteligencia artificial, mucha gente se ha animado a programar. Lo cierto es que es relativamente fácil.

A mí me parece genial. Siempre he dicho que programar potencia nuestro pensamiento lógico y nos ayuda a resolver problemas, siendo una actividad que recomiendo incluso a los más pequeños de la casa.

Como ingeniero informático, siempre he sido bastante crítico con la teoría vs la práctica de la educación en este país y he puesto en valor la formación profesional, donde un alumno sale con una capacidad operativa tremenda frente a las carreras tradicionales, donde la teoría, al menos en España, representa demasiada parte de la formación.

Con los grados de informática especializados (sistemas, programación, web, etc.) parece que se ha equiparado la parte práctica con la FP. Aún así, hay gente que pone en duda esta formación respecto a lo que comentaba al inicio: busco un curso por internet y con varias aplicaciones, programo.

Desde luego que vas a programar, pero informática no es sólo eso. Es mucho más, y las cualidades que desarrollas en el grado así como la experiencia generada durante las prácticas, son importantes para ello y tu futura carrera profesional. En informática, al igual que en otras carreras, una cosa es que funcionen las cosas y otra, que funcionen bien. Yo mismo he sido testigo de ello en numerosas ocasiones cuando he cometido (y visto cometer) errores que sólo la práctica y la experiencia te ayudan a evitar.

Os muestro algunos ejemplos de lo que un mal diseño informático o una mala programación pueden causar. Todos ellos recientes, de este mismo 2023; incluyo las consecuencias derivadas de los mismos.

• Reino Unido pagará 700.000 euros a los despedidos por un fallo informático. El software de contabilidad de las oficinas del servicio postal británico calculaba pérdidas inexistentes, que la fiscalía persiguió como fraude. 705 funcionarios fueron detenidos por un robo inexistente, algunos de ellos acabaron en la cárcel (sin pruebas, dado que todo se debió a un fallo informático), y cuatro incluso se suicidaron.

• Toyota detiene la fabricación en 14 fábricas de Japón. El fallo de sistema que obligó a parar la producción de sus 14 fábricas en Japón se debió a la falta de espacio del servidor durante unas labores de mantenimiento. ¿Os ha pasado que intentáis meter muchas fotos en el pendrive y éste os dice que no hay espacio? pues básicamente es lo que le pasó a Toyota y provocó que el sistema se detuviera en 28 líneas de producción de 14 fábricas.

• Las aerolíneas de Reino Unido piden al gobierno que les pague por los retrasos causados a más de 2.000 vuelos. El fallo de los vuelos de Reino Unido fue una variable repetida. El sistema de entrada de los planes de vuelo permitía incluir dos puntos con el mismo nombre en el recorrido, pero sin una lógica específica para diferenciarlos a posteriori. Lo que en el argot informático se denomina un bucle sin fin. Os explico, se podía incluir MAD y MAD como puntos del futuro recorrido del vuelo, pero como luego no había forma de diferenciarlos, no se sabía cuál iba primero y cuál después, por lo que el sistema colpasaba.

En los tres casos, los problemas que causaron los fallos eran aspectos básicos que una política de calidad del software o de definición de procesos hubiera evitado.

No lo llevo al terreno de un mal programador, dado que cualquier informático experimentado puede cometer fallos. La diferencia radica en que, si diseñas sistemas de control y calidad, minimizas o erradicas estos potenciales problemas. Y ahí es clave la experiencia y conocimientos que se imparten en los grados, algo que es difícil de conseguir por tu cuenta.

Es curioso que, a medida que avanzamos tecnológicamente como sociedad, parece que todo se vuelve más complejo. En mis tiempos, hacer una aplicación como la que en su día elaboré para ADIF/Renfe nos llevó exactamente un año a un equipo de 6 personas. Una aplicación que sería utilizada a nivel nacional.

Hoy en día ves desarrollos mucho más pequeños que se extienden en el tiempo, ¿por qué?. Yo tengo dos teorías para ello:

• Antes se programaba a más bajo nivel. Más simple. Cada vez usamos entornos de programación más complejos pero que permiten una programación más rápida y eficiente. Quitamos el valor de la lógica al programador para recortar tiempos. Y eso a la larga, se paga.

• Los sistemas de software modernos son cada vez más complejos, lo que requiere más tiempo y esfuerzo para desarrollarlos. El usuario pide más, lo que complica la arquitectura y muchas veces no desarrollamos desde cero, sino que tenemos que adaptar la petición del cliente a lo que ya existe.

• Las empresas están cada vez más centradas en la calidad del software, lo que lleva a un mayor tiempo de desarrollo y pruebas. Lógicamente los ejemplos que antes expuse no apostaban demasiado por la calidad.

Las metodologías de desarrollo ágiles, como Scrum y Kanban, están diseñadas para reducir el tiempo de desarrollo, pero no todo el mundo sabe cómo implementarlas de manera eficiente en los procesos de desarrollo actual. Mucho menos si se han formado por cuenta propia.

Yo mismo me certifiqué en Scrum el año pasado, dado que lo considero de gran valor para mantener mi formación y mi capacidad operativa al día. Y eso teniendo en cuenta que ya no trabajo como informático, sino como consultor SEO. Aún así, sigo pensando que el saber no ocupa lugar y que una formación contínua mantiene nuestras capacidades al día.

Como demostró nuestro ilustre Santiago Ramón y Cajal, las neuronas se regeneran, así que igual que entrenamos los músculos en el gimnasio, debemos mantener activo nuestro cerebro.