Legacy Applications: ¿re-escribir o mantener?

En este artículo evaluaremos las situaciones por las cuales las empresas deben responderse esta pregunta, profundizando el análisis sobre las causas para mejorar las posibilidades de éxito del proyecto y, sobre todo, no volver a tropezar con la misma piedra en un par de años.

Muchas veces he escuchado al desarrollador superhéroe decir: “Esta aplicación ya no sirve, debemos reescribirla”. Tantas otras veces he visto estos proyectos fracasar luego de meses o años de trabajo. Lo primero que debemos determinar es si estamos ante una aplicación soberana [1] en cuyo caso debemos tomar con mucho cuidado el proyecto de reemplazo o de mantenimiento.

En general la situación anterior, en la que el superhéroe propone el cambio drástico, viene acompañada de uno o más de los siguientes motivos:

• Años de falta de mantenimiento adecuado.

• Obsolescencia de la tecnología de base

• Dificultad creciente en el agregado de nuevas funcionalidades.

• Ausencia de documentación apropiada.

• Disolución (o huida) del equipo de desarrollo.

Todos estos motivos tienen algo en común: debieron haberse evitado y, si no aprendemos la lección, es seguro que los repetiremos una y otra vez. Repasemos algunas ideas para controlar estos problemas y como las Metodologías Ágiles y Scrum pueden ayudar.

Falta de mantenimiento y actualización de la tecnología de base.

Una solución de software depende de muchos componentes externos al código escrito por el equipo de desarrollo: bases de datos, componentes de terceros, entornos de ejecución, porciones de código descargadas de internet, etc.

La solución a este problema debe ser analizada en dos fases. En primer lugar, en la fase de diseño, debemos decidir cuidadosamente qué tecnologías utilizamos y, sobre todo, cómo las utilizamos.

Comencemos por la base de datos: Todos los proveedores ofrecen características que mejorar una u otra operación, la hace más sencilla y hasta más conveniente desde algún tipo de vista.

Sin embargo, éstas características especiales, por definición, serán difíciles de encontrar en otros proveedores y hasta podrían ser discontinuadas en futuras versiones del mismo proveedor.

Recomendación: el equipo debe esforzarse por utilizar las características básicas de la base de datos.

Otro caso podría ser el de algún componente o fragmento de código de terceros que nos permite salir del paso rápidamente, aunque no entendamos bien cómo funciona. Esto puede ser un problema en el futuro cuando ya haya desaparecido todo soporte.

Recomendación: evalúe cuidadosamente si utiliza componentes de terceros y, si lo hace, genere una “envoltura” con el nivel de abstracción apropiado para poder reemplazarlo cuando sea necesario.

Más allá de las decisiones de diseño, inevitablemente tendremos que utilizar elementos no controlados por el equipo de desarrollo.

La otra fase en que debemos controlar este problema es en el mantenimiento evitando la

“deuda técnica” [2]. Para ello el equipo debe revisar periódicamente la actualización de los componentes o tecnologías de base y aplicar las actualizaciones o reemplazarlas en caso de que hayan sido discontinuadas.

Esta es una responsabilidad del equipo y de todos los interesados, dedicando una porción de tiempo a esta importante tarea.

Dificultad creciente en el agregado de nuevas funcionalidades.

Los últimos 40 años de la industria del software demuestran que, a menos que hagamos un esfuerzo, el software se deteriora, su estado empeora.

No me refiero a los conceptos indicados en el apartado anterior, tampoco quiero decir que se oxida o que se rompe como un dispositivo físico, quiero hablar de otro problema conocido como software rot [3].

Software rot es otro tipo de deuda técnica. Es la deuda técnica que introduce el equipo de desarrollo por apuro, por desconocimiento o, simplemente, por descuido. No me atrevería a decir cuál de los tres motivos es más frecuente, apuesto a que es un empate triple.

El descuido y el desconocimiento pueden y deben ser controlados internamente en el equipo prestando atención al aprendizaje continuo, al intercambio de conocimientos, a la investigación aplicada, etc. En otras palabras, tratando de no caer en la deuda de innovación [4].

Recomendación: Existen muchas técnicas concretas para motivar al equipo a aprender y a cuidar la calidad interna del código pero creo que la más eficiente es el coding dojo [5], una actividad en la cual el equipo de desarrollo dedica frecuentemente (una vez a la semana) un espacio de tiempo acotado (una o dos horas) a aprender y a compartir conocimientos, ya sea con una nueva tecnología o técnica de desarrollo.

En cambio el “apuro” es algo que debe ser atacado desde el equipo y todo su entorno puesto que se debe a múltiples causas.

Una de las causas es la deuda técnica, de la que hablábamos antes, pues hace que las tareas sencillas se transformen en complejas y las complejas en imposibles. De esto se desprende que, si controlamos la deuda técnica de la manera recomendada tendremos más tiempo disponible, es decir, menos urgencias.

Otra forma de deuda técnica son los trabajos manuales requeridos en muchos casos debido a que el software no soporta completamente las necesidades del negocio debido a que nunca hubo tiempo de programar esa funcionalidad.

Recomendación: deben identificarse las tareas imprevistas más frecuentes, evaluar posibles soluciones, estimarlas y priorizarlas con las demás funcionalidades, junto con el responsable de producto o usuario para desarrollar la solución.

Una manifestación adicional de apuro se debe a las imprevisiones de los usuarios finales o responsables del producto que llevan al equipo a realizar con muy poco tiempo tareas extensas

por caer en la cuenta de fechas críticas a último momento.

Ausencia de documentación apropiada.

La documentación es uno de los subproductos más cuestionados y menos atendidos en el desarrollo de software. Incluso las metodologías ágiles se asocian, injustamente, con la “no documentación”.

La documentación es un artefacto más del software que el equipo debe desarrollar y mantener con la misma calidad y atención a la calidad que el propio software.

De la misma manera que el código, la documentación debe mantenerse en buen estado, eliminar la que resulta redundante o innecesaria.

Recomendación: revise periódicamente la calidad de la documentación, su actualización y, sobre todo, su relevancia. No hay nada peor que escribir con máxima eficiencia una documentación innecesaria.

Disolución (o huida) del equipo de desarrollo.

No trataré aquí la disolución programada de un equipo de desarrollo por culminación de un proyecto. Interesa más, desde el punto de vista de este artículo, la disolución espontánea del equipo, aquella que ocurre porque sus integrantes se agotan y marchan a buscar mejores experiencias.

La falta de objetivos de negocios claros, el cambio continuo de prioridades, las presiones con las fechas de entrega y las jornadas de trabajo extensas, atentan contra la motivación y, una vez que la motivación se ha perdido, la caída de la productividad, la calidad y la huida final del profesional, son cuestión de tiempo.

Recomendación: No tengo otra recomendación que leer el párrafo que sigue.

¿Como ayuda Scrum? (y las metodologías ágiles en general)

Scrum [6] es un marco de trabajo pensado para mejorar, al mismo tiempo, la productividad, la calidad y satisfacción en forma sostenible.

La productividad global del equipo en términos de valor aportado al negocio, software funcionando en manos del usuario.

La calidad, pues es imprescindible para que los defectos del software o los rechazos por el no cumplimiento de las funcionalidades pedidas, impacten negativamente en retrabajo.

Y la satisfacción de todos los involucrados (desarrolladores, responsables de infraestructura, usuarios finales, etc.) pues es también imprescindible para que la combinación anterior sea sostenible en el tiempo.

Scrum no logra esto mágicamente. Lo logra basándose en los principios del manifiesto ágil [7] y definiendo un nuevo juego de responsabilidades para el trabajo en equipo.

Uno de los roles es el Product Owner, cuya responsabilidad es el diseño del mejor producto posible para las fechas estipuladas. Para lograrlo, lógicamente, debe priorizar y decidir el mejor camino para maximizar el valor de negocio del esfuerzo de desarrollo.

Otro de los roles es el de Miembro de Equipo o simplemente equipo, cuya responsabilidad es la de desarrollar con la máxima calidad y productividad el producto. El equipo también debe lograr que este trabajo pueda ser mantenido en forma indefinida, es decir, que su rendimiento pueda ser sostenible y predecible.

Por último, el ScrumMaster es el responsable de ayudar a que el marco de trabajo anterior funcione perfectamente como un reloj suizo.

Por supuesto que hay mucho más que decir de Scrum pero eso es materia de otro artículo.

Referencias

[1] Cooper07: About Face by Cooper, Alan, Reimann, Robert & Cronin, David ISBN 9780470084113

2007

[2] Techincal Debt: http://en.wikipedia.org/wiki/Technical_debt, http://martinfowler.com/bliki/TechnicalDebt.html

[3] Software rot: http://en.wikipedia.org/wiki/Software_rot

[4] Innovation debt: http://blog.pbell.com/2013/03/19/innovationdebt/

[5] Coding dojo: http://codingdojo.org/

[6] Scrum: http://agileatlas.org/atlas/scrum

[7] Agile manifesto: http://www.agilemanifesto.org/