“Podrían haber muchos culpables en un escenario como éste”, señaló Sweeton, de Stout Systems. “Uno muy común es un defecto fundamental en el plano arquitectónico, donde el marco de la casa no soporta lo que estamos tratando de construir. En ese caso, puede ser un marco demasiado pequeño o demasiado grande -uno demasiado grande es más común de lo que parece”.

Si tiene suerte y la estructura es buena, puede que no tenga que derribar todo el esfuerzo y comenzar de nuevo.

“Aquí es donde la palabra de moda ‘refactorización’ entra en juego”, añadió Sweeton, y agregó que el primer paso en la refactorización de un código es volver a sus necesidades.

“Yo entendería las necesidades, y luego revisaría el código para ver si está cumpliéndolas -y las no declaradas, como calidad y facilidad de mantenimiento”, indicò Sweeton. “Si hay problemas arquitectónicos, entonces se debe averiguar cómo debería ser realmente y conseguir ponerlo todo en su lugar”.

Esto no siempre significa quitar y reemplazar. Al igual que con una casa, cuando se encuentra con problemas de código, hay maneras de mejorar la situación general en lugar de arreglar los errores de los dueños anteriores con las justas. Haga correcciones graduales y cada vez que el código necesite trabajo, añada una mejora -corrija los errores, anotó Sweeton. Y refactorice, refactorice, refactorice.

Si se trata de un proyecto que solo se utiliza internamente en lugar de un producto de consumo, tiene una mejor oportunidad de quedarse con él en lugar de reemplazarlo.

“Pero si está siendo utilizado por millones de personas”, indicó Estrada de Verizon, “entonces los pequeños cambios pueden hacer una gran diferencia en términos de costo. Si realmente está creando una mala experiencia de usuario o cuesta mucho dinero, entonces es probable que haya una mejor manera. Es el momento de empezar de nuevo”.

El dúplex accidental

Esta pesadilla común de proyectos de software enfatiza la importancia de la visión fuerte y el liderazgo. Las partes interesadas se ensamblan, y comienza la riña. Los usuarios, administradores e ingenieros no pueden ponerse de acuerdo sobre cómo llevarlo a cabo, así que el enfoque recae en tratar de complacer a todo el mundo, con el encargado de proyectos recogiendo exigencias de todos. Para el momento en el que el proyecto es enviado a ingeniería, la imagen general se pierde.

“Este es un problema común”, indicó Estrada. “Lo que termina pasando es que se obtienen requisitos de casi todo el mundo, entonces nadie sabe lo que se está tratando de lograr o lo que se debe hacer primero. Por supuesto, luego se unen más y más problemas”.

En otros casos, los ejecutivos y gerentes de proyecto quedan atrapados en la toma de notas -prioridades y proceso- en lugar de encontrar la mejor solución global.

En cualquier caso, pronto tiene el equivalente a tres cocinas construidas especialmente para ciertas comidas, dos baños uno al lado de otro, y un garaje al que nadie puede entrar. Se propuso encontrar una sola solución para todo y terminó con innumerables proyectos pequeños alojados bajo el mismo techo. El resultado no satisface a nadie.

Antes de siquiera pensar en qué hacer con el código en este tipo de trabajo de rehabilitación, tiene que volver al punto de partida -esta vez, dicen nuestros profesionales, con visión. Todos tienen que estar de acuerdo en qué plan es el más adecuado.

“Tiene que tener una base en términos de la arquitectura para asegurarse de que cumpla con lo que estamos tratando de hacer”, señaló Estrada. “Tiene que conseguir el aporte de todos los interesados, pero alguien de la gerencia debe liderar esa visión, o se obtiene muy mala arquitectura en términos de diseño de software”.

Con el nuevo plan unificado en su lugar, puede volver al código con un propósito y listo para priorizar mejor y solucionar el problema.

“Al establecer prioridades, básicamente está diciendo: ‘¿Qué cosas vamos a hacer hoy o esta semana?”, anotó Jacobson de Netflix. “La pregunta correcta es: ‘¿En realidad esto merece importancia? Y si la respuesta es afirmativa, entonces haga que suceda -y si no, entonces haga que desaparezca”.

El marginado

No es raro que un proyecto de software se deje sin terminar, con el desarrollador ausente. Tal vez el núcleo se ha esbozado, algunas funciones han sido implementadas, pero el contratista, tienda dev, o empleado que puso en marcha el proyecto, simplemente decidió irse para no volver jamás. El código funciona, apenas o en lo absoluto. O tal vez el proyecto se terminó, pero carecía de un plan de mantenimiento y está cayendo en desuso. ¿Y ahora qué?

En primer lugar, las malas noticias: Si usted hizo la contratación, no hay mucho sentido en señalar con el dedo. “Si una persona creó toda la cosa, el problema puede ser el gerente”, anotó Jacobson. “Y si usted es el gerente, ha hecho un mal trabajo”.

Todos nuestros profesionales ofrecen el mismo consejo: evitarlo en primer lugar. Una forma de planificar para esta contingencia es capacitar al equipo para asegurarse de que más de una persona entienda el código fuente.

“Digamos que el equipo que se encarga del proyecto tiene seis desarrolladores”, señaló Estrada. “Uno de ellos está trabajando en algunas de las funcionalidades para pagos en línea, otro está haciendo la gestión de cuentas personales o presentando los datos al usuario. Rótelos. En lugar de asignar a la persona que construyó la funcionalidad original, consiga una persona diferente para solucionar problemas o crear nuevas características. De esa manera se familiarizan con esa zona y con el código fuente. Si la persona que trabaja en la gestión de cuentas se pierde en algún viaje al extranjero y nunca regresa, alguien más puede retomar el trabajo sin sufrir demasiado”.

Si los consultores están creando el código, Sweeton agrega que sigue siendo importante tener a varios desarrolladores cerca: “Involucrar a un consultor independiente tiene un riesgo inherente si no cuenta con desarrolladores directamente contratados en su personal. Haga una contratación directa o involucre a una empresa consultora que maneje el proyecto de desarrollo con redundancia de recursos”.

El pozo de dinero

Las cuentas -o cuentas por pagar- de esta remodelación son tan extremas que harían que un cónyuge se fuera. La arquitectura tuvo problemas desde el principio, y como era previsible, barcos cargados de dinero en efectivo no resolvieron el problema. ¿Cómo dejar de tirar dinero a la basura?

A veces el instinto es priorizar y cavar su salida. Pero luego usted termina con una larga lista en la que todo -y nada- es urgente. El tiempo pasa, más problemas son reportados, y el resultado es una acumulación que tomaría años en resolverse.

“Se convierte en un juego táctico del gato y el ratón”, anotó Jacobson. “No se ataca con una visión clara”.

Decida qué es importante, dicen nuestros profesionales, y no se pierda en los gradientes de importancia.

Jacobson explicó: “Estaba teniendo una conversación con uno de mis compañeros, quien estaba diciendo, ‘tenemos que añadir esto a la lista de prioridades, ya que sigue siendo evitado y no ejecutado”. Y yo dije, ‘está claro que no es importante; no lo añadamos a la lista. Si fuera importante, estaríamos haciéndolo. O si es importante, entonces tenemos que dejar de hacer todo lo demás…'”.

En algunos casos, los gerentes ven una empresa externa como la solución para arreglar el problema, pero los consultores pueden agravar los errores si el propósito del software no es transmitido de manera clara por los encargados de la contratación. La empresa sigue desperdiciando dinero en el problema -cuando la solución no es acerca de los costos.

“Los consultores realizarán aquello por lo que se les contrató”, señaló Estrada, “pero ya que no hay una visión clara de lo que se supone que deben hacer -por ejemplo, están agregando más características, pero ese podría no ser el objetivo final de la compañía. Se necesita un buen conjunto de administradores de programas que puedan comunicarse entre todos los grupos para asegurarse de que se esté creando la funcionalidad correcta”.

El desmontaje total

A veces un trabajo de rehabilitación no es un trabajo de rehabilitación en absoluto. La base tiene grietas evidentes, y todo el mundo puede verlas. La arquitectura está tan mal diseñada que necesita ser destruida y comenzada de nuevo. Pero, ¿cómo saber cuándo es el momento de tirar todo el proyecto? ¿Por qué no mantenerse con el código y exterminar los problemas?

“Aquí está la prueba de fuego: si está gastando más tiempo en los errores que en la funcionalidad, entonces necesita repensar la aplicación y empezar de nuevo”, señaló Estrada de Verizon. “Si se trata de un mosaico completo que necesita un mantenimiento constante, entonces está perdiendo mucho tiempo”.

Es una tarea de enormes proporciones para ser tirada y comenzar una nueva. No todo el mundo va a estar contento por eso. Si una demolición es necesaria, nuestros profesionales dicen que comunicarles eso con eficacia a los diversos grupos de trabajo es el primer paso.

“Durante los primeros dos meses en Netflix”, recordó Jacobson, “básicamente dije, ‘esta aplicación que todos ustedes están utilizando, vamos a deshacernos de ella. Vamos a cambiar el enfoque'”.

Pero abandonar inmediatamente el sistema no suele ser una opción. En el proyecto de Jacobson, habían demasiados dispositivos heredados en la plataforma existente y hubiera tardado mucho tiempo adaptarse a las nuevas herramientas.

“Quedamos en que vamos a invertir en un modelo fundamentalmente diferente”, anotó Jacobson, “uno más optimizado que no es de talla única para todos -y va a ser trabajoso para mis equipos y también para los otros equipos que tienen que usar ese en vez del anterior. Tenemos que arriesgarnos y confiar en nosotros mismos. Eso es lo que hicimos. Y funcionó”.

La crujiente nueva construcción

Una nueva construcción siempre conduce a cierta sedimentación. Las tuberías tiemblan. Las vigas crujen. Pero cuando sigue ocurriendo, usted comienza a preguntarse: ¿esto es normal, o es necesario una reparación? Un gerente de producto sabio dijo una vez sobre el código recién lanzado: “Todos los nuevos bebés lloran”. Estaba haciendo que los usuarios sepan que el sistema no estaba roto -eventualmente se asentaría.

“Los padres aprenden la diferencia entre llantos”, señaló Sweeton. “Es mejor no hacer nada con algunos. Otros son el llamado genuino de angustia. Corra -no camine- para manejarlo. Lo mismo pasa en el desarrollo de software”.

Determine el mínimo producto viable, indicó Sweeton, y concéntrese en eso. Mientras que está trabajando en eso, averigüe qué es lo que puede esperar. “Mantenga una lista de todos los demás elementos que necesitan atención, pero aplácelos hasta después del primer lanzamiento”.

Tiene que ser clarividente, comenta Jacobson. Mirar la realidad de la situación y reunir las pruebas. Luego, hacer su recomendación. Aquí, las métricas para evaluar la salud del proyecto -y el costo de la curación- es la clave.

“No solo he tenido esta gran idea, o no la he construido, así que quiero construir lo mío. Por ejemplo, ‘hemos hablado con un número de desarrolladores, estamos invirtiendo este número de horas de desarrollo luchando contra este sistema, estamos exponiendo mayor riesgo a nuestra disponibilidad ya que estamos manejando este número de solicitudes. En efecto, nosotros estamos produciendo complejidad y bugginess’“, indicó Jacobson.

Además, añadió que si el modelo actual está fallando por su propio peso, es el momento de crear una opción más fuerte y más saludable para el futuro. “Sean cual sean esas métricas -aquellos puntos de datos que exponen a la debilidad del sistema actual-, son el combustible para decir ‘esto tiene que desaparecer'”.

El retrofit

El caso en el que la base es sólida es cada vez más común, pero las técnicas que lo produjeron son anticuadas. La tecnología utilizada puede haber sido la decisión correcta en su momento, pero ya no. Tal vez demasiadas dependencias ya no son compatibles. O se basa en tecnología antigua que pocas personas saben cómo utilizar. ¿Puede usted apoyar este proyecto y mantenerlo en marcha, o es hora de traer la bola de demolición?

Estrada recuerda su trabajo en una aplicación donde existía una presión para utilizar HTML5, que parecía la última y mejor opción. Pero a medida que el proyecto avanzó, muchas ineficiencias se hicieron evidentes -aún no estaba lista para el horario estelar.

“Rehicimos el proyecto en C++, y se necesitó mucho más esfuerzo, porque C++ es un nivel mucho más bajo”, señaló Estrada. “Pero logramos un mejor rendimiento. Si su plataforma es creada correctamente, se desarrolla un proceso que hace que sea fácil añadir nuevas características”.

Los consultores podrían encajar bien aquí, agregó Estrada, donde se tiene una tecnología aislada que necesita una reforma. Pero hay una advertencia: él sostiene que la incorporación de asesores es, usualmente, una mala elección para arreglar una herramienta interna en necesidad de nuevas funciones. Si la herramienta está ligada a otros sistemas, los consultores no tendrán el cuadro completo o una inversión a largo plazo en el resultado.

“El proceso de negocios debería conducir el software”, anotó Sweeton. “Descifre el proceso de negocio adecuado, luego adapte el código a este”.

Si los sentimientos de Sweeton sugieren un tema, hay una buena razón para ello. Los proyectos en Runaway tienden a carecer de uno de los tres elementos: una visión clara de la dirección, jefes de proyecto que se comuniquen con eficacia, y un fuerte liderazgo tecnológico. ¿Los proyectos que no cuentan con los tres? Tienden a necesitar renovación en más de un nivel.

Paul Heltzel, Infoworld EE.UU.