Y según parece, lo que ocurre dentro de los servidores es muy similar a lo que ocurría en el Viejo Oeste, donde los cadáveres podían estar durante horas o días tirados en la calle tras un tiroteo.
Cuando una aplicación deja de tener sentido, bien porque la empresa ha abandonado una línea de negocio o simplemente porque la aplicación ha sido sustituida por otra nueva, es habitual que nadie se acuerde de que se deja un muerto, en forma de activo de TI, tirado por la calle.
Durante una primera etapa no se le presta mucha atención porque todos los cariños van dirigidos a la nueva aplicación. Pasado ese primer momento, cuando teóricamente habría tiempo suficiente para hacer el levantamiento del cadáver y enterrarlo adecuadamente, ocurre que ya pocos se acuerdan de ella, todos pasan a su lado impasibles, como si hubiera formado parte del paisaje desde siempre. En cualquier caso, es claro que nadie ve alicientes en dedicar tiempo a esa vieja aplicación que ya no sirve a nadie. Esto mismo, en menor medida, aplica también al código muerto que hay dentro aplicaciones vivas.
Un poco de tiempo para revisar lo inservible
Es cierto que este problema solo lo sufren aquellas empresas con un cierto bagaje en el mercado, no tanto porque las nuevas aplicaciones se gestionen mejor, sino porque no han tenido tiempo suficiente para dejar morir -o matar- algunas de esas aplicaciones. Pero tras treinta años de desarrollo de aplicaciones, lo que se encuentra bajo las alfombras puede ser impresionante, con ratios de código muerto y aplicaciones sin uso por encima del 40 por ciento de las líneas de código.
Tener todos esos objetos no válidos implica sobrecostes en los procesos de evolución tecnológica, en la gestión de proyectos de mantenimiento y en los proyectos de migración de plataformas. Solo por eso ya merece la pena embarcarse en proyectos de renovación tecnológica.
www.tonsofit.com