Prisioneros del Software

Llevo unas semanas involucrado en un tema que me resulta bastante recurrente: ayudar a un cliente a lanzar una nueva versión de un software existente, esta vez a ser posible con ciertas garantías de que el software no sufrirá de “mortalidad infantil”. Hablo de la reescritura desde cero de un software, sin usar ni considerar (a nivel constructivo, es decir, de diseño y programación) nada de lo ya existente. Se trata de un software con bastantes funcionalidades, que ha reportado grandes beneficios a la empresa. De hecho, es la base de su negocio, con lo que además es una pieza estratégica y, por lo tanto, crítica en la empresa...



El círculo vicioso

¿Por qué cambiarlo? El software en cuestión se ha vuelto imposible de mantener: cualquier cambio acaba desatando gran cantidad de problemas y bugs, el rendimiento no es el deseable, es costoso de modificar por su pobre diseño, el código está totalmente “prostituido”… seguro que a más de uno le resulta familiar.

El problema es que el software funciona.

Desde la perspectiva de la empresa, el software es una herramienta para resolver un problema, no un fin en sí mismo, y por lo tanto si un software se usa es que funciona, puesto que en mayor o menor medida cumple con su cometido (también podría ser que no hubiera más remedio que usarlo, pero no es el caso).

Y ¿por qué es un problema que funcione? Pues porqué cuando un sistema funciona, tiende a crecer.

El software y todo lo que le rodea (usuarios, empresas, negocios, datos) son organismos "vivos", y en el software, entendido como herramienta, sucede algo que no sucede con el resto de herramientas: CRECE. Esto solo sucede con los organismos vivos. El usuario, como “ente vivo” que es, tiene que adaptarse al medio, y para ello requiere de nuevas herramientas. Sin embargo, con las “herramientas software” las quiere hacer crecer, ampliarlas, en lugar de reemplazarlas por otras herramientas nuevas, mejor adaptadas, en principio, a la nueva realidad de su medio.

La situación que pretendo describir se da normalmente con software que lleva cierto tiempo en operación; mal vamos si un software nuevo ya está tan mal, aunque también se da esta situación (hablemos de ello otro día). Se trata, por lo general, de software con cierto grado de complejidad, a la construcción del cual se ha dedicado una elevada suma de dinero (o tiempo, que es lo mismo), bien sea un software desarrollado por un tercero o construido por la propia empresa (lo que más adelante llamo “cliente interno”). Sea cual sea el caso, se trata un activo de importante valor. Por lo tanto, deshacernos del mismo significa eliminar un importante activo de la empresa, lo que a nivel financiero es un problema, puesto que hablamos de eliminarlo, no de venderlo. Este es el principal motivo por el que ciertos managers se niegan a “matar” este tipo de programas casi insostenibles, lo que resulta en un gravísimo error. Cuando se comete este error, irremediablemente le sigue otro: añadirle más funcionalidades. Entonces tenemos un software muy costoso de mantener, que nos gustaría eliminar pero nos cuesta hacerlo por el gran valor que tiene, al cuál le estamos añadiendo todavía más valor, dificultando así aun más que pueda ser reemplazado. La dificultad de reemplazarlo viene, llegado este punto, por dos o tres motivos:

1. Como decía, significa deshacerse de un activo de importante valor


2. La reconstrucción del mismo, la obtención de un software sustituto (puesto que es una herramienta necesaria), es más costosa en tiempo y, por lo tanto, en dinero, pues para conseguir el mismo grado de funcionalidades es necesario un mayor esfuerzo


3. Si el software es un producto o servicio que vendemos, o la base de ello, el tiempo de puesta al mercado de la nueva solución es también mayor, aumentando el coste de oportunidad al no poder aplicar durante este tiempo funcionalidades nuevas

Pero la necesidad de reemplazarlo es clara, pues hay 2 problemas graves que resultan ya infranqueables:

1. Añadir cualquier funcionalidad nueva supone un coste mayor, posiblemente en grados de magnitud, de lo que debería, dado que:


1. la complejidad para añadir nuevas funcionalidades es mayor, ya que el estado actual es de un software poco modular, posiblemente con una elevada densidad de errores, sin documentar o mal documentado y con gran cantidad de código que posiblemente interactuará con la funcionalidad que vamos a añadir, puesto que el diseño del software no es el que sería deseable


2. debido a la anterior razón, el tiempo para añadir nuevas funcionalidades es también mayor de lo que debería


3. no hay tests automatizados, por lo que la calidad del software percibida por el cliente se ve afectada. Si hubiera tests y se hicieran pruebas de regresión, al menos se podría confiar en no romper lo que ya funciona o en no introducir cualquier bug


2. Cada vez que añadimos funcionalidades a dicho software estamos aumentando su complejidad, aumentando así su coste de mantenimiento futuro y posiblemente también su coste de operación

El resultado es que hemos entrado en un círculo vicioso para el que no hay solución (salida) óptima: somos prisioneros del software.


Escapar

Debemos escapar de esta situación. No importa a qué extremo se ha llegado en el círculo vicioso, cuanto antes salgamos mejor. ¿Cómo debemos salir? evidentemente, matando el software. Pero, ¿Cómo?

For every complex problem, there is an answer that is short, simple and wrong (H. L. Mencken)

Primero debemos plantearnos cuáles son los principales impedimentos que vamos a encontrarnos:

1. Los usuarios. Puesto que el sistema funciona, los usuarios serán reacios a cambiarlo por otro.


2. Los managers. Por lo habitual según mi experiencia, lamentablemente son pocas las empresas que tienen buenos procedimientos de desarrollo de software; es por ello que el management puede ser reacio a dejar cambiar el software, pues tiene miedo –históricamente justificado en la mayoría de casos— a que no se pueda sustituir en los plazos comprometidos, es decir, a que las estimaciones planteadas por el equipo de desarrollo no se cumplan. Otra razón es el riesgo que puede suponer una decisión de este tipo cuando el software en cuestión es una importante fuente de ingresos en la empresa. Por lo tanto, el problema de base es la falta de confianza del management hacia el equipo de desarrollo en lo que a estimaciones se refiere (justificada en muchos casos).

Para matar el software hay que fijar 2 fechas críticas:

1. Fecha de fin de producto (end of product): es la fecha a partir de la cual, bajo ningún concepto, se va a realizar ningún otro cambio al software, pase lo que pase, a excepción de bugs críticos. Se mantiene el soporte a usuarios, sin embargo. Si se trata de software comercial, lo deseable es disponer en esta fecha de una versión mínima de la nueva versión del producto.


2. Fecha de muerte(end of life). Me hace gracia el eufemismo que usan los anglosajones, “fin de vida”, en lugar de “muerte”. En fin, se trata de la fecha en la que el producto es abandonado por completo, es decir, en la que ya no hay soporte a usuarios, corrección de bugs ni nada.

La cuestión clave aquí es que para poder poner una fecha de muerte, es necesario disponer de una fecha en la que, casi sin posibilidad de error, tendremos la nueva versión del producto.

Esto implica que debemos disponer de un equipo con experiencia como equipo, que pueda estimar tiempo y costes bien, y que se disponga de un procedimiento de desarrollo de software (que no solo de construcción) probado, disciplinado, sistemático y cuantificable, y que dicho procedimiento sea bien conocido por el equipo de desarrollo.

Pero, ¿qué sucede cuando el equipo, históricamente, ha fallado con las fechas de lanzamiento previstas? (da igual si es por culpa de cambios constantes en requisitos o de lo que sea) Entonces el management no confía en las fechas que le damos. Para ello es necesario convencer con hechos y hacer lo que debería hacerse en todo proyecto: implicar al cliente (sea un cliente externo o interno). ¿Cómo lo implicamos?:

• haciendo que participe en todas las reuniones de toma de requisitos y de seguimiento de proyecto


• descomponiendo los requisitos en tareas pequeñas, agrupándolas en hitos (milestones) a corto plazo, como a 1 semana, y en ciclos de desarrollo cortos (de 1 mes) que acaben con una entrega parcial totalmente operativa (aunque puede ser, y normalmente será, incompleta) al cliente, aumentando así la visibilidad del cliente sobre el progreso del proyecto


• atacando primero aquellas partes del proyecto que tienen más riesgo, aumentando así la previsibilidad del proyecto al reducir el riesgo (lo que se llama estrechar el cono de incertidumbre), y ante el mismo nivel de riesgo, atacando primero aquellas tareas que aportan más valor al cliente en relación con su requisito de negocio, aumentando así el ROI de la entrega y, consecuentemente, del proyecto; de esta forma aumentamos más rápidamente el valor del proyecto, por lo que conseguimos reducir el coste del cambio


• informando periódicamente (cada semana o cada vez que lo solicite) al responsable del proyecto por parte del cliente del estado del proyecto, facilitándole pleno acceso a los documentos de seguimiento de proyecto y trabajando conjuntamente para resolver cualquier posible problema que creamos que podemos tener en un futuro en el mismo momento en que lo creemos posible, no cuando lo tenemos encima

Evitar ser capturado

A scientist builds in order to learn; an engineer learns in order to build (Fred P. Brooks)

Para evitar ser capturado de nuevo solo hay un camino: aplicar un enfoque sistemático, disciplinado y cuantificable a las tareas de desarrollo, operación y mantenimiento del software; es decir, a todo el proceso de desarrollo, no solo a la construcción (diseño detallado y programación).

Así mismo, debido a la idiosincrasia particular del software y a las tendencias actuales, en que el tiempo de puesta al mercado y de adopción de cambios prima más que cualquier otra cosa, debemos adoptar unos procedimientos que sean adaptables al cambio, que sean flexibles. A un arquitecto no se le pide que construya un rascacielos encima de una casa de planta baja sin tocar los cimientos; a un ingeniero de software, sí.

No es necesario adoptar una metodología existente en concreto. Con frecuencia, da mejores resultados adoptar buenas prácticas y establecer una metodología propia, basada en alguna existente, pero adaptándose a las características particulares de aquél entorno concreto: experiencia y tamaño del equipo, tipo de software, requisitos de negocio, distribución geográfica del equipo,… Está claro que este tipo de decisiones sobre buenas prácticas y metodologías debe tomarlas alguien con basta experiencia y conocimiento en la materia.

Por último, es de vital importancia la mejora continua. Debemos establecer mecanismos de mejora continua y seguirlos estrictamente, para aprender de nuestra experiencia constantemente y disponer de una buena base histórica para afinar las estimaciones. Somos humanos y aprendemos de los errores.

Como dice mi mentor (gracias Pere por tus impagables enseñanzas):

L’experiència és molt bona, però sempre vé tard.
(La experiencia es muy buena, pero siempre llega tarde)