Cambios: ¿ El principio del fin de nuestro software?

El ciclo de vida del software, desde que nace como un proyecto hasta sus etapas de mantenimiento y evolución, muchas veces transita por escenarios turbulentos.

Estos escenarios turbulentos a medida que el software crece, provoca que los cambios que se deban implementar, demanden cada vez mayor esfuerzo, dejándolos casi obsoletos al final.

Pero ¿a qué hacemos referencia con “escenarios turbulentos”?, ¿por qué estos escenarios aumentan el esfuerzo en la implantación de cambios en el software? ¿Pueden estos escenarios terminar con nuestro software? ¿Cómo podemos evitarlo?

Veamos punto por punto.

Escenario turbulentos

Todo software es creado para brindar soporte a un negocio específico, pero en la actualidad, donde la innovación marca el camino, los tiempos del negocio se aceleran y exigen al software estar a la altura para impulsarlo o hacerlo mas competitivo.

Ahora bien, esta necesidad de negocio de adaptar al software en tiempos cortos para dar un valor agregado inmediato puede traducirse como un “escenario turbulento” cuando provoca que terminemos generando un descuidando la estructura del software.

Aumento de esfuerzo o de costos y tiempo

A medida pasa el tiempo una suma de estos escenarios turbulentos provoca que, el software que brinda soporte a nuestras operaciones sea cada vez más rígido y nos encontremos con mayor dificultad para incluir nueva funcionalidad. Para implementar cada cambio y adaptar el software a nuestras necesidades (que cambian con gran rapidez) es necesaria una mayor cantidad de recursos.

Finalmente nos encontramos con que aplicar los cambios que necesitamos es tan costoso como construirlo desde cero y que la pendiente crece negativamente.

Es cuando nos preguntamos ¿Qué pasó entre el release1 y el release50 que el costo es un 100% mas caro?.

Nuestro CFO advierte este escenario y puede que como resultado, muchas veces se deje de incorporar funcionalidad vital para el negocio y finalmente se termine operando con un software que de a poco deja de generar valor y cae en la obsolescencia.

Otras veces, se prefiere comenzar de cero, con la convicción que no volverá a pasar, garantizando que esta vez “se hará bien”, “esta vez entenderemos mejor el negocio”. En este caso, si no podemos identificar lo que falló seguramente volveremos al problema origen.

Entonces debemos pensar ¿Cuál es el problema de origen? ¿El mercado que no para? ¿El negocio que no se define bien? ¿O nosotros hemos olvidado una punto clave en la construcción? Seguramente la respuesta tiene que ver con ésto último.

¿Qué estamos haciendo mal?

En algún punto dentro del ciclo de desarrollo convertimos que lo fue Soft en lo que es Hard. Definitiva dejamos de desarrollar software.

Claramente hicimos lo necesario para que lo que debía ser fácil de cambiar ya no lo sea y convertimos nuestro software en algo más similar a lo que es hardware, es decir, agregar nuevo comportamiento es una tarea difícil donde los devs insumen una cantidad de esfuerzo importante para moldear donde hay rigidez.

Es entonces cuando debemos recordar que el software nace justamente para solventar este problema; nace para poder agregar comportamiento a máquinas de una manera sencilla.

Convertir nuestro soft en hard hará que nuestros esfuerzos para implementar cada ongoing feature requiera mayor dedicación a la resolución de problemas estructurales que implementar la naturaleza del alcance del cambio que el negocio requiere avistando de a poco el fin del ciclo de vida de nuestro producto.

¿Cuál es la solución entonces?

Una forma sencilla de no volver a este punto es aplicar Ingeniería de Software, que trabaja en la forma de los cambios para que las piezas sean lo más livianas y flexibles posible contando con la versatilidad que un negocio requiere.