Nací en el 78, una gran generación. Fue justo después de que la Crisis del Software de finales de los 60 y principios de los 70 obligara a los grandes pensadores de la época —Myers, Constantine, Dijkstra, Parnas, Brooks…— a sentar las bases de nuestra disciplina, la ingeniería de software. Ellos no estaban allí para discutir el framework de moda, sino para evitar que los sistemas desarrollados hasta la fecha colapsaran bajo su propia complejidad.

Y es sorprendente cómo, a día de hoy, seguimos cometiendo exactamente los mismos errores que entonces. A cada nueva hornada de profesionales parece olvidársele que el software —y hoy más que nunca la infraestructura— no es un ente estático, sino un producto sujeto a cambio y mantenimiento constante. Siempre digo a mis alumnos que esta frase debería venir de serie: si quieres dedicarte a esto, tienes que asumirla desde el día uno. Ignorar esto fue la raíz de aquella crisis y es lo que hoy sigue devorando presupuestos y equipos que salen al mercado como si la historia no fuera con ellos. El resultado es predecible: sistemas que funcionan hoy, pero que son el lastre de mañana.

Lo advirtieron los grandes pensadores tras la crisis del software: el problema no era la falta de herramientas, tampoco la falta de talento; era la falta de principios para construir sistemas que soporten el cambio. Y ahí es donde pongo el foco.

Quizá por mis estudios de Ingeniería de Minas, tengo muy presentes ciertos conceptos. El primero de ellos es la definición de ingeniería: resolver un problema bajo restricciones de tiempo, dinero, recursos, seguridad y operación. En ingeniería, cumplir estas restricciones no es un "extra"; es parte integral de la solución.

Pero hay más cosas que en aquella época se integraron en mi ADN (mis primeros proyectos también ayudaron), como mi obsesión por la mantenibilidad. Una mina se diseña para operar durante décadas. La Ingeniería de Minas es una disciplina con 3 siglos de antigüedad, donde el conocimiento está muy asentado y la viabilidad a largo plazo es una condición física, no un concepto abstracto. Hay un rigor que viene de trabajar con horizontes largos y consecuencias reales que condiciona cómo piensas, y que se va transmitiendo generación tras generación.

La ingeniería de software apenas tiene 60 años; es una disciplina joven. Y aun así, vivimos en un mundo hiper-informatizado. Un mundo, eso sí, en el que la mantenibilidad parece una preocupación secundaria. Olvidamos continuamente que el software, como una mina, debe ser diseñado para lo que viene después de la inauguración.

Soy un entusiasta de los conceptos teóricos, quizás porque los estudié siendo muy pequeño. Nos ayudan a cumplir restricciones sin pagar el precio en mantenibilidad. Ya hubo gente hace muchas décadas que tuvo los mismos problemas, dedicó muchas horas a pensar en ello y llegó a soluciones y conclusiones que siguen siendo válidas hoy.

En entornos serios, esto se sabe desde hace décadas: el software se escribe una vez, pero se lee y se mantiene mil veces. Este principio, que ya estaba en las bases del lenguaje Ada hace más de 60 años, es una de mis reglas de oro.

Diseño sistemas pensando en el profesional que tendrá que operarlos y evolucionarlos dentro de tres años. Para lograrlo, pongo el foco donde de verdad se decide la supervivencia de un sistema, utilizando principios como SoC o DRY, o conceptos como cohesión y acoplamiento, o cualquiera de las decenas de pilares que hoy se ignoran en favor de debates estériles sobre herramientas. La herramienta cambia; el fundamento permanece.

En el mundo nuclear no se diseña “para entregar”. Se diseña para vivir décadas con seguridad y eficiencia. Una central está pensada para operar durante mucho tiempo, y por eso la gestión del mantenimiento y del cambio no es un detalle: es el corazón del sistema. Ese fue el contexto de mis primeros años profesionales, y por eso estos conceptos los tengo grabados a fuego.

A principios de los 2000 diseñé el sistema de control de incidencias de la central nuclear de Cofrentes, que ha seguido operativo por más de 25 años. Cuando trabajas en ese nivel de horizonte temporal, aprendes una lección simple y brutal: el coste de construir es pequeño; el coste real de un sistema aparece en la operación, el mantenimiento y la evolución. A esto se le llama Coste de Ciclo de Vida (LCC).

Ese mismo concepto aparecía en la construcción naval. A finales de 1998 comencé a diseñar el sistema de publicaciones de mantenimiento de la Armada Española, proyecto en el que anduve involucrado por más de 8 años. Durante ese tiempo tuve la suerte de trabajar en muchos astilleros mientras diseñaban y construían nuestra hornada de Fragatas F-100 (a día de hoy siguen siendo puntales de la flota española). En ese entorno, el coste de ciclo de vida es una realidad palpable: el coste de construir un buque es solo una fracción del coste total que representa su operación y mantenimiento durante décadas.

Te aseguro que es impresionante ver realizar un overhaul a un submarino dentro de la Gran Carena —desmontar el submarino completamente, revisar cada componente, reparar o sustituir lo que sea necesario y volver a montarlo— y entender que el coste de ese proceso es lo que realmente define la viabilidad de la solución. Una solución definida más de una década atrás en el tiempo.

Lo mismo ocurre con el software: el coste de escribir código es solo la punta del iceberg; el verdadero coste se revela a medida que el sistema se opera, mantiene y evoluciona. Ojalá estuviera más de moda en el mundo IT formar a los profesionales en este concepto… Es algo que me digo cada vez que me llaman para impartir formaciones de LCC en el sector naval y militar.

Y ese es el enfoque que aplico hoy: no busco que el código “funcione ahora”. Busco que el coste de operarlo y mantenerlo dentro de los próximos cinco años no devore al equipo, al presupuesto y al producto.

Un sistema que no es mantenible no es una solución; es un pasivo, una hipoteca que se firma con cada línea de código, cada configuración, cada decisión de diseño.

Ese es el criterio con el que trabajo: el que separa el oficio de la improvisación.

El vacío de conocimiento es especialmente crítico —y peligroso— en el mundo de la operación, y especialmente en lo que conocemos como DevOps, donde se está operando con una falta de principios de ingeniería preocupante. Muchos perfiles en esta área no vienen del mundo del desarrollo y carecen de estos conceptos fundamentales de diseño.

Mucha gente llega a Ops/DevOps por caminos distintos al desarrollo, y por eso a veces no se transmite bien este cambio: hace años que ya no se trata de “administrar sistemas”, sino de automatizar esa administración; dicho de otra forma, crear programas que administren esos sistemas por ellos. Y si no se aplican los mismos principios de diseño, modularidad y calidad que en el desarrollo de software, el resultado será el mismo de siempre: sistemas cada vez más complejos, frágiles, con deuda técnica creciente y costes que se disparan.

Estamos igual que hace 70 años, pero en un mundo mucho más dependiente de la tecnología. Hoy la infraestructura es, a efectos prácticos, software.

IaC no es describir la infraestructura en un pseudoprograma usando un DSL de moda. Es tratar la infraestructura como software: versionado, revisión, pruebas, ciclo de vida y mantenimiento. Y, por supuesto, aplicando los mismos principios de diseño que aplicas al código.

Conozco las herramientas y las tendencias. Pero mi foco principal es otro: criterio y fundamentos para que la tecnología sea una solución y no una carga. Y lo aplico igual en formación que en consultoría: del diseño a producción, del código a la infraestructura.