Nadie puede concebir que se derrumbe una casa recién construida por el mero hecho de que entren en ella unas cuantas personas (de tamaño y comportamiento normal, quiero decir ;)) o que suba un par de personas en un coche nuevo y el coche no pueda andar porque no aguante el peso. Podemos pensar multitud de ejemplos absurdos como los descritos y, en cualquier caso, si llegaran a ocurrir dichas situaciones, sabemos que no tendríamos problema en que la garantía de esos productos o construcciones cubra ese desastre a coste cero, porque para eso está la garantía y nosotros revisamos hasta el último detalle cuando adquirimos uno de estos bienes y reclamamos al más mínimo fallo. Eso es algo absolutamente natural, ¿verdad?.
Pensemos ahora en el software. ¿Cuántas veces y con qué frecuencia se nos puede “caer” un software recién desarrollado?, ¿cuántos detalles podríamos encontrar que no cumplen con lo esperado?. Y ¿qué hacemos en caso de que se nos caiga o de encontrar esos errores de diseño?. Pues generalmente llamar a quien lo ha construido y, por regla general, volver a pagar por un gran número de horas para que se arregle (o intente arreglar). Aunque habrá cosas que ya no se podrán arreglar como la falta de servicio producida, el desprestigio ante nuestros usuarios/clientes o el malestar producido.
Como en todo aspecto de nuestra vida, la calidad técnica de un desarrollo de software es un factor clave fundamental del éxito del mismo. Pero por lo general no le solemos prestar mucha atención y nos centramos muchísimo más en revisar exclusivamente los aspectos funcionales, lo que damos en llamar el “testing funcional”, intentando, además, que dicho testing no interrumpa el proceso de despliegue, que no “entorpezca”... ¿Identificáis la situación de la siguiente viñeta?
Cuando se construye un software, a la diferencia entre cómo se debería construir correctamente (desde un punto de vista técnico) y como se ha construido realmente se le conoce como “deuda técnica” (en este artículo, nuestro compañero Antonio Calero profundiza en este concepto). Esa deuda, si las cosas no se hacen correctamente, se irá incrementando o acumulando con el tiempo y provocará que cada vez cueste más implementar nuevas funcionalidades o simplemente mantener ese software. Es como si se tratara de una hipoteca que nos ha concedido un banco.
Seguir desarrollando nuevas funcionalidades sin solucionar esos problemas técnicos equivaldría a seguir pidiendo más dinero al banco cada vez, con lo que nuestra deuda crece y crece. Por el contrario, corregir esas carencias técnicas equivaldría a amortizar deuda con el banco y que nos quede cada vez menos deuda que devolver al banco.
Pues bien, hoy en día, en lo referente a desarrollos software, lo normal es hacer caso omiso de esa deuda técnica y seguir implementando nuevas funcionalidades sobre un software determinado, a pesar de que sepamos que ese software adolece de una mala calidad técnica. Y puede llegar un momento en que dicha deuda sea tan grande que nos asfixie y haya que “tirar” ese software y volver a desarrollarlo desde cero, imaginemos el coste que habrá tenido dicho desarrollo.
Pero esto no tiene por qué seguir siendo así ya hoy en día. Tenemos normas (ISO 9126, ISO 25000) que nos ayudan a medir la calidad de un desarrollo técnico, plataformas como QAlitaXque nos facilitan esa labor al 100%, obteniendo centenares te métricas de un desarrollo software y modelos de calidad (también implementados en plataformas como QAlitaX) que nos permiten agrupar dichas métricas individuales para dotarlas de semántica y saber qué significa que un conjunto de métricas tengan un determinado valor.
Uno de esos modelos (de los muchos que hay) es precisamente el de “deuda técnica” que, en base a las métricas obtenidas de analizar un desarrollo software, determina la deuda técnica de dicho desarrollo.
Una vez conocida la deuda técnica de nuestro software, hemos de priorizar absolutamente los esfuerzos en minimizarla, en no seguir añadiendo nuevas funcionalidades con esa deuda, porque esas nuevas funcionalidades se desarrollarán también con deuda e incrementarán la deuda global del desarrollo y cada vez costará más mejorar y desarrollar el sistema.
"Conocida la deuda técnica de nuestro software, hemos de priorizar absolutamente los esfuerzos en minimizarla"
Es como si, sabiendo lo torcida que está la torre de Pisa, siguiéramos añadiéndole pisos encima porque la gente los demanda. Seguramente que se acabaría cayendo al suelo o costaría infinitamente más enderezarla por cada piso que añadiésemos.
Por lo tanto, ante una situación de deuda técnica (muy común, por desgracia) lo que hemos de hacer es centrarnos principalmente en amortizar esa deuda, “invertir” todo el tiempo posible en minimizarla y luego seguir evolucionando el sistema con nuevas funcionalidades.
Es por esto por lo que se recomienda muy encarecidamente que los análisis de calidad técnica de un desarrollo software y el conjunto de medidas para minimizar la deuda técnica del mismo se han de hacer por un equipo técnico ajeno al propio desarrollo, ya sea del mismo equipo de desarrolladores como del jefe de proyecto o coordinador técnico del mismo. De lo contrario, sin darse cuenta, el equipo vinculado al desarrollo terminará por “tapar” ciertos problemas y minimizando el impacto técnico y volviendo a priorizar las funcionalidades por encima de la calidad técnica.
"Los análisis de calidad técnica de un desarrollo software se han de hacer por un equipo técnico ajeno al propio desarrollo"
Si no lo hacemos así, lo más seguro es que, antes o después, esa deuda acabe por ahogarnos y acabemos teniendo que desechar ese software o gastar tanto dinero en mantenerlo que se vuelva absolutamente inmanejable desde el punto de vista de la gestión. La “torre” se nos caerá y luego nos quejaremos de la inmadurez de nuestra querida ingeniería del software… Trabajemos para que no se nos caigan "nuestras torres", porque es la mejor inversión de futuro que podemos hacer en nuestros sistemas software
