La metáfora de la deuda técnica (si no sabes a qué me refiero échale un vistazo a este post), nos da la gran posibilidad de transmitir a personas no-técnicas, y desde un punto de vista económico, los problemas que implica el software de mala calidad, la necesidad de hacer buen código, la necesidad de refactorizar el código, etc.
Sin embargo, aún nos queda un “pequeño” problema por resolver… actualmente no hay una única manera de cuantificar la deuda técnica de un software.
Tampoco hay un consenso sobre qué debe considerarse deuda técnica. Por ejemplo podemos encontrar que dentro de deuda técnica queda incluida la falta de cobertura de pruebas, pero también que nuestro software dependa de una plataforma específica, que el desarrollador no entienda bien como aplicar un patrón de diseño, o incluso que la arquitectura de nuestro software no sea la más adecuada.
Y entonces, ¿hay alguna formula para calcular la deuda técnica? Sí, varias. ¿Y cuáles son? Varios autores proponen diferentes fórmulas para cuantificar la deuda técnica. Pero aún así, podemos agrupar las principales fórmulas en dos grupos:
1 –Estimación del valor de deuda técnica del proyecto, sin tener en cuenta los intereses que genera la deuda.
Por un lado, hay autores que solo enuncian fórmulas que se centran en dar un valor de la deuda técnica actual del proyecto, sin calcular sus intereses en el futuro. Dentro de este grupo, nos encontramos a los creadores del plugin de deuda técnica de la herramienta Sonar o Jean-Louis Letouzey con el método SQALE (puedes saber más sobre ellos aquí y aquí).
A grandes rasgos, ambos cuantifican la deuda técnica basándose en encontrar ciertas malas prácticas en el códigoy los costes que conlleva solucionar esas malas prácticas.
En el caso del plugin de Sonar se detecta el código duplicado, violaciones (como por ejemplo nombrar a un método que no es un constructor igual que a una clase o no emplear métodos get() y set() …), no comentar APIs públicas, complejidad ciclomática que supera un cierto umbral, cobertura de pruebas menor de un cierto valor y dependencias entre paquetes que superen un valor concreto.
2 – Con intereses
Otros autores, pretenden llevar la metáfora de deuda técnica más allá, y no sólo dan mecanismos para calcular el valor de deuda técnica actual (al que llaman principal), sino que empiezan a hablar de distintos tipos de intereses que genera la deuda técnica.
A pesar de que en este grupo los autores tienen en común que están de acuerdo en diferenciar entre deuda técnica principal e intereses, plantean distintos enfoques:
- Chin, Huddleston y Gat, consideran que la mayoría del software atraviesa períodos de desarrollo activo al comienzoy mantenimiento después. Por ello, su fórmula de deuda técnica es la suma de la deuda técnica acumulada en el período de desarrollo más la deuda técnica que se acumulará en el período de mantenimiento. Todo ello teniendo en cuenta distintos tipos de intereses.
- Para Bill Curtis, Jay Sappidi y Alexandra Szynkarski, la deuda técnica principal, se calcula obteniendo los problemas estructurales del código (a través de una herramienta de análisis), clasificando dichos problemas según su grado de severidad (alto, medio, bajo), estableciendo qué tanto por ciento de cada tipo de problema se va a solucionar, y el tiempo que tardaríamos en solucionar dicho problema.
- Gary Short, calcula la deuda técnica principal desde otra perspectiva, teniendo en cuenta aspectos como el número total de empleados que trabajan eliminando la deuda técnica, sus salarios, el coste de comprar e instalar el hardware que se necesite o incluso una estimación del daño que puede provocar la deuda técnica a la imagen de la empresa.
- Por último, Ariadi Nugroho, Joost Visser y Tobias Kuipers, calculan la deuda técnica considerando los intereses y basándose en un modelo de calidad propio creado por el grupo SIG (Software Improvement Group) basado a su vez en la ISO 9126. En este caso, el “interés” es el coste extra invertido en mantener el software por tener una mala calidad técnica. Además, también tienen en cuenta que tanto la deuda técnica como los intereses aumentan con el tiempo y proponen una fórmula para calcular ese crecimiento.
Por cierto, si te interesa todo esto, el día 25 de septiembre tenemos curso en Madrid sobre deuda técnica, en esta página tienes la información
postdoctorado en la Universidad Carnegie Mellon,
EE.UU. Es pionero en management, planificación,
estimación, product management, Agilidad y en la
aplicación de la inteligencia artificial generativa a la
gestión de la creación de productos y servicios
tecnológicos. Fue el único español en la primera
conferencia Ágil de la historia.
- OKRs sin Lado Oscuro, IA para OKRs y alternativas para evaluarlos - 25 julio, 2024
- Por qué seguimos usando técnicas ágiles anticuadas: Efecto Einstellung - 18 julio, 2024
- Cómo crear una IA personalizada (me llevó meses, pero te lo enseño en 2 min) - 11 julio, 2024
Una licencia SQALE en Sonar cuesta 2500€ al año. Y el developer cockpit 7000€ al año. ¿Quien se lo puede permitir? Desde luego un pequeño emprendedor no. Luego nos quejamos que Windows es caro..