¿Es rentable una migración desde cero?

Uno de los impulsos más difíciles de reprimir para un programador es el de ver un código antiguo, de esos que los años han ido degradando, y no caer en la tentación de rehacer esa funcionalidad que se nota que tiene ñapa sobre ñapa, que se hace de manera ineficiente, que tiene cincuenta mil ifs anidados…

Por otra parte, cada cierto tiempo, las empresas se plantean realizar migraciones de aplicaciones antiguas a una tecnología más nueva. Los motivos esgrimidos suelen ser aprovechar una infraestructura que ha ido mejorando con el paso del tiempo, que puede soportar un mayor número de usuarios, o mayor carga de trabajo.

Sin embargo, el software de dichas empresas puede no haber crecido a la par, por ejemplo porque cuando se desarrolló la aplicación no había esas necesidades, y no se incluyeron como requisitos no funcionales.

Ese es el momento en el que, armados con todas las herramientas estupendas que tenemos a día de hoy, te encuentras con la “fácil” tarea de realizar la migración. Y ya que estamos, como hacer esa migración es “tan sencillo”, pues ya aprovechamos y tenemos que incluir cierta funcionalidad que no tenía la aplicación original. Como todos sabemos, una migración es algo que “no produce valor añadido” – dicen – y claro, puede tener un cierto coste que, elevado o no, hay que justificar. Y de ahí el hecho de meterle “algo nuevo”.

¿Quién no se ha encontrado con una situación así?

Tras realizar la migración, el resultado habitual, y que sorprende a muchos clientes, es el siguiente:

  • La aplicación migrada suele tener más bugs que la original. Normalmente suele ser porque ese código tan feo suele cubrir los cincuenta millones de casos especiales que se presentan durante el proceso que cubre, y al que nadie hace caso en el momento de plantear la nueva solución. Generalmente, no es posible bajar al nivel del código para todo el sistema antiguo cuando se diseña el nuevo.
  • El rendimiento de la nueva aplicación suele ser menor. Esto pasa más a menudo de lo que pudiera parecer, por ejemplo cuando se migra una aplicación en entorno host (cobol) a tecnologías actuales (Java – .NET). Cierto, la tecnología moderna te proporciona mucha más funcionalidad de base, pero a un cierto precio. Acelera el desarrollo, pero no necesariamente el rendimiento.

De ahí que surja la pregunta: ¿realmente es rentable hacer una migración de una aplicación desde cero?

Mi opinión es que depende. Hay situaciones en las que puede interesar migrar. Pero en la mayoría de los casos, puede ser interesante pensar en la reutilización de ese sistema, por ejemplo aplicando una arquitectura orientada a servicios. La nueva funcionalidad se puede desarrollar con otra tecnología más actual, y ciertas partes del sistema antiguo se pueden ir migrando paulatinamente.

Y vosotros, ¿qué opináis?

P.D.: Al hilo, un artículo muy interesante.

5 comentarios en “¿Es rentable una migración desde cero?”

  1. Hola Augusto:
    Durante muchísimo tiempo estuve dedicado a migrarle a clientes, un software a versiones superiores del mismo. Nunca, jamás, never estuvieron satisfechos los clientes y la razón es obvia: Si haces un trabajo excepcional lograrás dejarle al cliente exactamente lo mismo que tenia antes de la migración solo que con una nueva tecnología y quizás alguna nueva característica que no siempre te han pedido. Es decir, que solución le aportamos al cliente en estos casos? ninguna, solo un nuevo requerimiento no funcional que es la tecnología. S, la tecnología como requerimiento es un antipatrón propio de esta industria. Ahora, el cliente lo mínimo que espera es que le funciones igual o mejor que antes pero como he dicho, eso es lo máximo que podrás entregarles.
    Y ahí tenemos un problema. Personalmente, si yo fuese un cliente y tuviese sobre mi la decisión de negocio de migrar o no y la aplicación ya la tuviese hace rato en producción controlada y estable, y me vienen con que sería bueno migrarla, yo los saco a las patadas. Esto muchas veces (no siempre) responde a que las empresas de soft necesitan actualizar sus productos para seguir en el negocio y los clientes se las comen de arriba. Claro está que no me quedaría con una aplicación en cobol aunque he visto muchísimas que funcionan extraordinariamente bien en la actualidad.
    Saludos.

  2. Hoy mismo discutia este tema con Rodrigo Corral, bajo mi punto de vista, creo que a veces es rentable y otras no, creo que las espectativas iniciales nunca se cumplen inicialmente pero si pueden cumplirse en un futuro cercano.

    Pero, haceros otra pregunta, porque aprender WCF, WPF, Workflow, etc, etc…, si con las herramientas actuales que dominas podras solucionarlo de una forma seguro mas rápida y efectiva, cuantas veces nos pasa esto?

    Creo que la solución es muy simple, hay que poner en una balanza las ventajas (mejora de la productividad, ampliar la funcionalidad, escalabilidad, etc, etc) y los incovenientes (Coste del desarrollo, depuración y puesta a punto, etc, etc), y tomar la decisión en base a estos dos valores, nada mas.

    Aunque me hace dudar la frase de Albert Einsten que dice:

    Los intelectuales resuelven los problemas, los genios los evitan.

  3. El artículo de Joel brilla por su sentido común (el menos común de los sentidos); es para suscribirlo al 100%. En las universidades debería haber una asignatura de Refactoring.

    Me gustaría hacer algunas reflexiones sobre el tan amado-por-algunos HOST, y variar la línea “editorial” para abrir la polémica ;-).

    La primera es que es un silo que es difícil de conectar con sistemas externos, en un mundo cada vez más conectado / distribuido / orientado a servicios. Te salva un MQ Series o un FTP que usas con más miedo que vergüenza, por no hablar de esos artilugios que rara vez funcionan como el SOAP “concatenado a pelo contra un WSDL”, o esa versión de WAS que corre en CICs y que es como las meigas.

    Por otra parte, su soporte de estándares de mercado es muy escaso, lo que dificulta su integración (supongo que porque es más viejo que dichos estándares ;-). También es verdad que eso nos da de comer a más de uno que trabaja en EAI.

    And last but not least, lo que no mucha gente sabe es que se suele facturar su uso por picos de MIPS (no por cpu o por cliente), lo que hace que las facturas suban astronomicamente (IBM vive de las rentas). Sé de algún caso de amputación genital por un bug consistente en un bucle infinito… 😉

    Estos requisitos no funcionales abren la puerta a muchas migraciones.

    Saludos, y ánimo con el blog.

    Emilio

  4. El cliente tiene su código y su funcionalidad. Por un lado no le gusta reconocer que el código se ha hecho bastante insostenible, lo ha pagado y su gente muchas veces está implicada, por lo que los responsables de informática no se van a echar tierra. Por último han hecho un buen trabajo, pero muchas veces no tienen preparación suficiente, por lo que el resultado es funcionalmente correcto y después de retorcarlo el código ha quedado hecho una pena.
    Migrar quizás es una forma de refactorización del sistema a lo bestia. Que ventaja tiene??? Pues saber que hace el código realmente y limpiarlo de código basura.
    Por último, en ciertas ocasiones que el código sea una basura es el tesoro de muchos porque donde podrían trabajar 10 personas trabajan 100. Quien gana? 90 personas no las consultoras.
    Tenemos que ganan las consultoras y que los responsables no quieren asumir riesgos ni culpas entonces tenemos UNA CONCLUSIÓN QUE MIGRE MANOLO EL DE LA MOTO. Todo el mundo gana, menos el cliente, aunque el cree que no pierde, porque por otro lado el gasto desgraba.

  5. Otra cosa es como hacer que todo vuelva a funcionar como antes…
    El problema es que en muchas ocasiones no se sabe que hace realmente el código. Alguna vez me han dicho no toques eso, porque lleva ahí no sé cuanto tiempo y nadie se ha quejado… pero si no vale para nada… si es posible pero quien lo prueba.

    Es decir, se tiene un código nada documentado y una funcionalida desconocida. En este momento es cuando migrar se pide a gritos, pero es como intentar reanimar a un muerto. Entonces cual es la estrategia para hacerlo??? Pues, encomendarse a dios y tener paciencia.
    Para llenarlo de errores siempre hay tiempo y lo que habría que cambiar es la metodología con la cual se han hecho las cosas. Por ejemplo automatizar las pruebas para que la funcionalidad a probar quede recogida en un documento y un programa de pruebas automático.

    Vender esto es muy difícil en fin como dijo alguien pocos conductores miran bajo el capo mientras el coche arranque por las mañanas.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *