No es el tema más 'sexy' de la escena tecnológica. De hecho, para muchas personas resulta un asunto peliagudo que temen como si de una pesadilla se tratase. El muerto viviente que la industria TIC lleva queriendo matar desde hace décadas y, sin embargo, sigue vivito y coleando. Hablamos, como no, del código heredado o 'legacy code'.

Sistemas como los mainframe y lenguajes como COBOL datan de los años 60 y 70, cuando los avances digitales eran ínfimos en comparación con lo que disponemos en la actualidad. Resultan extraordinariamente complejos, difíciles de mantener y desconocidos para las nuevas generaciones de programadores.

Pero ahí están. Este 'legacy code' sigue presente en la mayoría de grandes compañías del mundo e incluso configura el corazón de la banca o la propia Administración Pública. Y pese a todos los intentos por modernizar estas aplicaciones, la realidad acaba imponiéndose y perpetuando estos despliegues.

Hay una persona que entiende esta disyuntiva como nadie. Se llama Michael Feathers y está considerada como la voz de referencia para hablar de código heredado. Autor del archiconocido libro Working Effectively with Legacy Code, Feathers es uno de los pioneros del movimiento 'agile' y defensor a ultranza del potencial que estos sistemas más antiguos todavía pueden ofrecer.

Michael Feathers, nombrado a principios de año arquitecto jefe de Globant, comparte con D+I sus reflexiones sobre este tema, imprescindible hoy como lo era hace sesenta años.

¿De dónde viene su interés por el 'legacy code'? No es un tema que resulte atractivo para mucha gente del sector y, sin embargo, usted incluso ha escrito libros sobre ello...

Básicamente fue algo natural por mi experiencia laboral. Me mudé a la consultoría justo en el momento en que comenzaba el desarrollo ágil de software y ayudaba a las empresas a adoptar estas prácticas tempranas en torno a algo llamado programación extrema. 

Gran parte del enfoque en aquel momento era lograr que las compañías usaran el nuevo software correcto de una buena manera. Pero comencé a encontrarme con clientes que tenían muchas aplicaciones antiguas y empecé a ver con ellos cómo abordar ese 'legacy code' que se interponía en su camino. 

Me di cuenta de que ese conocimiento era muy valioso y que no era común dentro de la industria. Por eso pensé que sería útil escribir un libro sobre eso.

¿Por qué creías que sería útil ese libro? ¿Qué mensaje clave querías trasladar?

Siento que tenemos este sesgo dentro de la industria de pensar en lo nuevo y brillante. Pero la situación en la mayoría de organizaciones es que están rodeadas por los despliegues antiguos. Lo heredado es con lo que tienen que lidiar cada día. Y creo que podemos adoptar una actitud de exploración hacia estos despliegues y averiguar cómo aprovecharlos mejor en el futuro, en lugar de fingir que no están ahí. Quizás no sea lo que la gente quiere ver, pero creo que tiene un gran valor.

Cuando hablamos de aplicaciones heredadas normalmente el discurso se centra en cómo hacerlas trabajar junto a los nuevos desarrollos. Pero ¿cómo podemos darle valor a este 'legacy code', hacer algo distinto con él?

En gran parte se reduce a comprender las capacidades que están presentes en el software heredado que tenemos y descubrir qué es eso tan específico que hace ese software. Dicho de otro modo, separar las piezas más generales de las más específicas para poder reutilizar partes de ellas.

Por ejemplo, si se tiene un sistema de gestión de inventario para un supermercado, puede que haya una parte central de la aplicación que sea genérica de administración de inventario. Podría usarse para cosas que no sean solo comestibles y eso permitiría aplicar ese código en un dominio diferente. Este planteamiento nos permitiría ver las posibilidades comerciales que no se ven necesariamente en el mercado.

Una idea muy potente...

Lo es. Siempre recuerdo al respecto una vieja película sobre el Apolo 11 en la que se explicaba la historia de los astronautas. Estaban atrapados en el espacio y a punto de quedarse sin oxígeno. Y lo que hicieron en la base terrestre fue meter a todos los ingenieros en una habitación y poner en una mesa todos los objetos que había en la cápsula. Les dijeron: "Tenéis tres horas para averiguar cómo extender el suministro de oxígeno en la nave espacial usando solo estas cosas".

Llevando este pensamiento al terreno del 'legacy code', se trata de mirar detenidamente lo que tenemos y cuáles son sus capacidades. Luego podremos decidir reutilizar esas cosas de diferentes maneras, no sólo para resolver el problema actual frente a nosotros, sino también para esas nuevas oportunidades que quizás antes de este ejercicio no sabíamos que podíamos aprovechar.

¿Crees que las empresas están interesadas en este tipo de enfoque? Parece que el mensaje clave pasa por la estandarización y la modernización de todos los sistemas, especialmente para aprovechar el máximo potencial de la IA o el análisis de datos...

Considero que debemos hablar más sobre esto para que la gente pueda entender estas oportunidades. Es una de las cosas a las que me enfrento todo el tiempo, porque vengo de una formación muy técnica y me encuentro con la separación entre ese campo y lo comercial. De un lado no ves las oportunidades del otro, y viceversa. 

Como tecnólogo puedo ver a menudo situaciones en las que hay posibilidades que aún no son visibles para la empresa. La idea es ir y tratar de sacarlas a la superficie. Hacer esa evaluación sólida de cuáles son las capacidades del software, las aplicaciones heredadas y sus implicaciones en el dominio empresarial. 

En muchos casos, y especialmente a raíz de la migración a la nube, lo que estamos viendo es que estas aplicaciones heredadas simplemente se meten en contenedores y se pasan a los entornos 'cloud'. Sin reescribir ninguna línea de código ni buscar ese potencial que comentas. ¿Cómo podríamos administrar esos despliegues antiguos en la era moderna de forma más eficiente?

Meter estas aplicaciones en contenedores y moverlas a la nube es un enfoque decente solo para hacer esa transición. Por supuesto hay cuestiones a tratar, como la falta de disponibilidad y los requisitos no funcionales que queremos tener en torno a ellas, pero creo que lo más profundo es lo que mencioné antes: separar lo específico de lo general para poder seguir reutilizando las piezas.

Antes de dar ese salto, las empresas deberían desarmar las aplicaciones en todos sus componentes, comprobar todos los procesos y buscar la mejor manera de dar respuesta a las necesidades de la compañía.

¿El hecho de tener que trabajar con lenguajes de programación complejos como COBOL puede ser un freno a la hora de acometer esas revisiones del software heredado?

Ya se han creado entornos más útiles a la hora de trabajar con el 'legacy code', pero sigue siendo más complicado que los nuevos lenguajes de programación. Pero no creo que sea una barrera insalvable: yo mismo nunca he trabajado en COBOL, a pesar de que escribí un libro sobre código heredado.

Como vengo del movimiento 'agile' creo que la clave no está tanto ahí, sino en cómo construir pruebas automatizadas que permitan cambiar las cosas más fácilmente. Hay mucho código que no está escrito en lenguajes modernos y es un código muy difícil de cambiar.

Obviamente tener mejores lenguajes es una gran facilidad, pero creo que es una maravilla la forma de abordar el código desde el punto de vista del proceso y la implementación de pruebas automatizadas para hacer que el cambio sea más fácil. Esta clase de tests son las que permiten que los ingenieros sepan si, al trabajar con este 'legacy code' han roto algo y arreglarlo de inmediato. 

Hablar del código heredado es especialmente relevante en tanto que suele usarse en las partes más críticas de las empresas. Por ejemplo, el mainframe sigue siendo el corazón de la industria bancaria a escala global. ¿Cómo podemos gestionar estos procesos que comentas cuando estamos tocando algo tan sensible para el negocio?

En algunos casos sencillamente no es posible gestionarlo. Es una suerte de compensación del riesgo y el beneficio que tienes que buscar. Hay que analizar si estratégicamente es una buena idea reescribir partes de ese 'legacy' o no. 

Aun así, en los escenarios en que se opte por no repensar estas aplicaciones heredadas, sigue siendo útil usar las pruebas automatizadas para caracterizar el comportamiento de este software lo suficientemente bien como para reescribirlo o extraer componentes en caso de que se desee en un futuro.

Por otro lado, siempre está la estrategia de crear una plataforma completamente nueva y que sirva de marco para futuros desarrollos, como una alternativa a intentar aprovechar los sistemas existentes y reutilizarlos. Son dos opciones realmente diferentes que se pueden tomar y que dependen del contexto de cada empresa.

Cuando hablas con un ingeniero, ninguno quiere hablar del código heredado ni de lenguajes de programación antiguos. A los jóvenes, especialmente, no les interesa este tema en absoluto. ¿Cómo podemos romper con estos prejuicios y devolver el interés en estas lides a la primera plana del sector?

Ese aspecto es muy interesante. Creo que en la educación y en la universidad debería incorporarse este aspecto. De hecho, cuando los desarrolladores entran en la industria, aprenden rápidamente que están rodeados de sistemas exitosos con restricciones a su alrededor. Solo tenemos que abandonar el sueño de que constantemente estamos haciendo cosas nuevas todo el tiempo. Es una realidad un poco dura, pero al mismo tiempo es una oportunidad. 

Querría finalizar esta entrevista dándole la vuelta a la conversación sobre el 'legacy code'. Siempre hablamos de estas tecnologías en pasado y, como mucho, en presente. Pero ¿qué será de los sistemas heredados -y la informática profesional en general- dentro de diez años, por ejemplo?

Es una reflexión muy divertida. Básicamente hemos intentado convertir estas aplicaciones en microservicios durante los últimos diez años de la industria y parece que es algo que va a durar bastante tiempo.

Aunque también deberíamos tener en cuenta que tendencias como la nube son como un péndulo y probablemente volvamos a más entornos 'on-premise' en un futuro. Es fácil de predecir porque nos hemos adentrado tanto en la nube que ya deberíamos estar mirando al espacio contrario. Todo el mundo espera que estés en la nube, todos marchan en una misma dirección, pero es esta clase de momentos cuando hay que pararse y preguntarse si deberíamos mirar en la otra dirección. Hay cosas que podrían ser muy valiosas y se pierden porque todos están enfocados en el mismo camino.