Una Guía Rápida y Completa para Medir tu Deuda Técnica y Utilizar los Resultados

Hola a todos. Mi nombre es Anton, y gracias por recibirme en TechLeadConf este año. En los próximos 20, tal vez 25 minutos, hablaré sobre la medición del liderazgo técnico e interpretación de los resultados. Espero que esta charla les sea útil e interesante.

Algunos detalles sobre mí, lidero organizaciones de ingeniería. Actualmente soy director de ingeniería en Westing en Alemania. También mentoro y doy coaching a otros líderes de ingeniería, como gerentes de ingeniería y principales ingenieros. Si estás buscando un mentor o un coach, no dudes en contactarme, siempre estoy disponible. También fuera del trabajo, soy padre y un gran fanático del esquí de montaña y el senderismo, entre otras cosas. A continuación, puedes ver mi nombre de usuario de Twitter y mi información de contacto, como mi dirección de correo electrónico y también el enlace para conectarte conmigo en LinkedIn. Y sí, con eso, comencemos de inmediato.

Comencemos con una sorpresa. ¿Qué les parecería si les dijera? Como dice nuestro querido amigo Morpheus, que no toda su deuda técnica realmente necesita ser resuelta. Apoyo completamente esta afirmación, en realidad, esta pregunta en particular. Y para entender cómo es que no toda la deuda técnica necesita ser resuelta y también cómo contradice una creencia relativamente popular de que la deuda técnica es generalmente la raíz de todo mal, veamos algunas cosas.

Entonces, empecemos por ¿qué es la deuda técnica? Si no es la raíz de todo mal. Fue el término acuñado por este tipo, Ward Cunningham, en 1992. Y él era mucho más joven en ese momento, porque esta es una captura de pantalla de su video explicativo en YouTube que publicó en 2009. Y el video se llama Metáfora de la Deuda Técnica. Y él habla en profundidad sobre esto. Aquí hay un par de citas, que no vamos a leer. Simplemente las pasaremos por alto. Entonces, según Ward Cunningham, el autor del término deuda técnica, no es la raíz de todo mal. Y lo que es, es una herramienta para acelerar temporalmente el desarrollo al elegir tomar atajos para acelerar ahora a expensas de ralentizar después. Al igual que tomar un préstamo, podemos permitirnos algo antes de ganarlo por completo, y luego tenemos que pagar intereses. Entonces, dado que es una herramienta, ¿la deuda técnica es inherentemente mala? Bueno, preguntémosle a nuestro querido amigo Morpheus y él nos dirá que la respuesta correcta es depende. Como muchas preguntas en el ámbito de la ingeniería de software, ¿en qué depende? Esa es la parte interesante, ¿verdad? ¿En qué depende, cómo podemos ver en qué depende? Bueno, primero, veamos cómo determinamos si tenemos deuda técnica en primer lugar. Eso lo podemos hacer al observar nuestro software y responder a una serie de preguntas. Primero, ¿es fácil de analizar y entender? Este fragmento de software. Segundo, ¿es fácil de modificar? Tercero, ¿es seguro modificarlo? Y finalmente, la cuarta pregunta, ¿hay algún requisito técnico necesario, por ejemplo, escalabilidad, estabilidad, requisitos de seguridad que no se han implementado? Y si respondemos sí a alguna de estas preguntas, tenemos deuda técnica en este fragmento de software.

Además, lo que me gusta distinguir son dos tipos de deuda técnica. El primero es la deuda técnica de mantenimiento. Esta es la deuda técnica relacionada con las primeras tres preguntas, que básicamente es la parte de la deuda técnica que ralentiza nuestros cambios, ya sean características o cualquier otro tipo de cambios en nuestra base de código. Simplemente los implementamos más lentamente debido a la deuda técnica, porque el diseño no es perfecto. Y la segunda parte de la deuda técnica es la deuda técnica continua. Lo que significa que necesitamos dedicar tiempo, debido a alguna deuda técnica en nuestra aplicación, a mantener la aplicación operativa. Y esta deuda técnica reduce el tiempo que podemos dedicar a introducir cambios en nuestra base de código. Así es como estos dos tipos de deuda técnica son diferentes, y así es como definen de manera diferente la respuesta a la pregunta, ¿cuándo se vuelve realmente mala la deuda técnica? Porque no toda es inherentemente mala, pero ¿cuándo se vuelve mala? Bueno, la deuda técnica continua es inmediatamente mala tan pronto como la implementamos en producción. Entonces, cualquier atajo, ya sea en confiabilidad, escalabilidad, atajos de seguridad, produce algunas consecuencias de primer orden como errores, tiempo de inactividad, violaciones de seguridad, Dios no permita que se roben datos, lo cual a su vez produce esfuerzo ad hoc, cambio de contexto, que como sabemos, es otro gran consumidor de productividad. A veces pérdida de ingresos, a veces cosas peores que eso, como daño reputacional a largo plazo, y así sucesivamente. Así que no queremos eso.

Y la deuda técnica continua es inmediatamente mala y plantea todos estos riesgos en nuestro producto. Ahora, la deuda técnica de mantenimiento solo se vuelve mala cuando necesitas introducir cambios en el área donde la tienes, lo cual tiene sentido. Porque si algo funciona, no te importa qué tan malo sea el diseño siempre y cuando funcione y no necesites introducir nuevos requisitos allí. Por ejemplo, estamos en el mundo de los microservicios, ¿verdad? Entonces, puede ser un microservicio simple, mal diseñado, creado hace 10 años, que está ahí y simplemente funciona y ha funcionado desde entonces porque no ha habido más requisitos que implementar y no hemos necesitado preocuparnos por la deuda técnica que está ahí.

Lo que todo esto significa es que las principales preguntas sobre la deuda técnica que debemos hacer son, en realidad, ¿cómo determinamos qué deuda técnica necesita ser resuelta, al menos en este momento, y también cómo determinamos cuándo la deuda técnica que necesita ser resuelta se está saliendo de control, de modo que nuestra lista de deuda técnica que realmente necesita ser resuelta a corto plazo se está volviendo demasiado grande para resolver a corto plazo? Y la respuesta a eso está en las métricas de deuda técnica o en las métricas relacionadas con la deuda técnica, que me gusta dividir en tres categorías principales, a saber, métricas heurísticas, métricas de segundo nivel y la categoría que solo contiene una, el interés de la deuda técnica, y verán por qué es tan especial. Spoiler alert, es especial. Así que empecemos una por una.

Métricas heurísticas de deuda técnica. Cuando escuchamos la palabra heurística, generalmente se trata de algo automatizado, ¿verdad? Y estas métricas no son una excepción, son automatizadas, generalmente son proporcionadas por las herramientas que ya existen. Y la mayoría de estas herramientas miden cosas como la complejidad del código ciclomático, la duplicación de código, los malos olores de código, otra cosa que fue popularizada por el tipo llamado Ken Beck en 1990, y luego promovida en gran medida en el libro Refactoring, que muchos de ustedes pueden conocer, escrito por Martin Fowler en 1990... publicado en 1999 en realidad, lo siento. Luego habría algo como el Índice de Mantenibilidad, que puede tener un nombre diferente, pero generalmente es la agregación de las métricas anteriores, y algo más potencialmente. Luego estaría la Relación TAGDAT, que es esta relación entre los Costos de Remediación de TAGDAT divididos por el Costo de Desarrollo. Desafortunadamente, a pesar de tener el costo aquí y de que se supone que esta métrica se trata del impacto comercial directo en dinero y demás, este costo es demasiado sintético e inexacto, porque generalmente se determina por la cantidad de líneas de código que tienes en tu base de código, multiplicado por algún cociente sintético, que es el costo de desarrollar una línea de código, lo cual puede variar dependiendo de la línea y rara vez es una buena métrica para mostrar el esfuerzo real. Luego habría otras dos métricas, algo como problemas de seguridad detectables estática o heurísticamente y también casos límite potencialmente omitidos detectables heurísticamente, que son especialmente importantes en lenguajes de tipado débil donde no tenemos compiladores para detectar esos casos. Y finalmente, estas métricas también se pueden dividir en esos dos tipos de deuda técnica de los que hablamos anteriormente, deuda técnica de mantenimiento y deuda técnica continua. Es solo que la deuda técnica continua aquí no es algo que nos tome por sorpresa, sino más bien algo que ya podemos detectar mientras analizamos el código y potencialmente solucionar, lo cual generalmente es una buena idea.

Ahora, mencionamos herramientas, ¿verdad? Estas son las herramientas que acabo de mencionar de memoria. Probablemente las más grandes, así que SonarQube y luego Code Climate Quality, creo que se llama así. Y hay otras herramientas, herramientas de línea de comandos, herramientas con interfaz de usuario y demás. Así que hablemos de las ventajas y desventajas de las métricas heurísticas de deuda técnica. Entre las ventajas, estará la facilidad para obtener los números o la base de código completa de una vez. Básicamente, una vez que elijas la herramienta y la configures, obtendrás estos números con toda la división necesaria entre módulos, carpetas, etc., en cuestión de minutos, ¿verdad? Luego estará la facilidad para segmentar las métricas. Obtener la división por módulo o lo que mencioné anteriormente. Y esto sería útil para detectar posibles puntos críticos. Lugares donde las métricas muestran más deuda técnica que en otros lugares, que serían algunos puntos en los que potencialmente querrías echar un vistazo más de cerca. Ahora, obviamente, también habrá desventajas. La primera sería que es difícil convertir estas métricas en la cantidad de trabajo real que requiere la deuda técnica detrás de ellas, porque, no sé, toma la complejidad ciclomática, sabes que en esta clase es como 15, o en este método, es 15. ¿Qué te da en términos del esfuerzo para solucionarlo? Prácticamente nada. Así que aún tendrás que investigarlo y estimarlo, interpretarlo de alguna manera.

Entonces, también es difícil convertirlos en impacto comercial. Nuevamente, una complejidad ciclomática de 15, ¿qué impacto comercial tiene? ¿Cuánto nos ralentiza o ralentiza el desarrollo de funciones? En realidad, no lo sabemos. Necesitamos investigarlo y estimarlo. También es muy difícil priorizar entre puntos críticos, porque, nuevamente, no conocemos el impacto comercial de esos puntos críticos, y es por eso que más deuda técnica según estos números no siempre significa más impacto comercial. Por lo tanto, esta priorización, solo con estos números, no nos da mucho. Eso es todo sobre las métricas heurísticas de deuda técnica.

Veamos el siguiente grupo. Las métricas de deuda técnica de segundo nivel, que en realidad no son exactamente métricas de deuda técnica, sino más bien las métricas de lo que influye o causa. Cosas como la división de esfuerzo entre soporte ad hoc y funciones. Puedes definir un umbral allí. Por ejemplo, todo lo que supere el 30% de gasto en soporte ad hoc podría ser problemático. Para algunos equipos, debe ser incluso menor para ser problemático. Entonces defines el umbral, pero es importante hacer un seguimiento. El tiempo de ciclo de los tickets de funciones. Tickets de funciones porque generalmente optimizamos para funciones en casi todos los equipos porque queremos introducir cambios lo más rápido posible porque luego mejoramos nuestro producto y mejoramos nuestros KPI comerciales, ingresos, etc., y queremos introducirlos lo más rápido posible. Entonces, si seguimos el tiempo de ciclo, veremos si nos estamos ralentizando, y no queremos eso. Luego estarán las tendencias de errores. Si abrimos más errores de los que cerramos de manera consistente durante un período de tiempo, entonces podemos tener problemas porque solo estaremos trabajando en errores, y luego la división de esfuerzo entre soporte ad hoc y funciones será demasiado preocupante. Luego estará el tiempo de actividad del software, una métrica bastante clara, y todo tipo de tiempos promedio, como el tiempo promedio para recuperarse de una interrupción, el tiempo promedio para detectar una interrupción y el tiempo promedio entre fallas, también conocidas como interrupciones, que básicamente nos muestran qué tan estables somos y cuánto tiempo nos lleva, o qué tan eficientes somos en términos de detectar las interrupciones y recuperarnos de ellas, porque todas las interrupciones son potencialmente una pérdida de ingresos, y, sí, queremos manejarlas rápidamente.

Ahora veamos los pros y los contras. El mayor beneficio de este grupo de métricas es que están directamente relacionadas con el impacto comercial, lo que significa que nos brindan una ventaja para priorizar los cambios relacionados con la deuda técnica frente a las funciones comerciales, que es lo que queremos, ¿verdad? Nos acercamos a nuestros interesados comerciales, les decimos, ok, aquí está cuánto impacto comercial traerá esta eliminación de deuda técnica, y ellos dicen, ok, eso está bien. Luego lo priorizamos por encima de esta lista de funciones, que es exactamente lo que queremos, ¿verdad? Luego, estas métricas son relativamente fáciles de recopilar, siempre que se sigan ciertasbest practices como el registro de tiempo en los tickets, el registro de trabajo y el sistema de seguimiento inicial y los tiempos de inactividad que se registran, lo cual es algo que de todos modos recomendaría que hagas. Y entre las desventajas, solo habrá una, pero importante. Estas métricas son realmente muy genéricas. Por lo tanto, es difícil relacionarlas con módulos de código específicos, clases, etc., para obtener exactamente lo que necesitas solucionar, lo que significa que aunque están directamente relacionadas con el impacto comercial, es más difícil prometer a los interesados comerciales que entregarás este impacto comercial, porque necesitas investigar y adivinar qué está impulsando exactamente este impacto comercial negativo que tienes ahora y que luego puedes solucionar. Y aquí es donde entra en juego nuestro tercer grupo, que consiste en una hermosa métrica llamada interés de la deuda técnica, centrándose en el nivel de los tickets para comprender su impacto. Ahora este es un concepto que fue descrito por Martin Fowler, el autor del libro Refactoring, en el año 2008. En el artículo que enlacé aquí, pero el concepto en pocas palabras es así. Es importante llegar al nivel de los tickets cuando quieres entender cuánto impacto técnico está teniendo en realidad. Porque para cada ticket, conocemos el esfuerzo que requirió, siempre que hayamos registrado esto, y deberíamos hacerlo.

Y con el equipo que ha trabajado en este ticket, también podemos estimar cuánto esfuerzo habría requerido sin la Deuda Técnica. Y aunque es una situación imaginaria, nunca no habría Deuda Técnica, solo podría haber muy poca Deuda Técnica, pero podemos hacer este ejercicio mental y suponer que llevaría tanto tiempo si no estuviéramos ralentizados por la Deuda Técnica. Y la diferencia entre estos dos es el Interés de la Deuda Técnica.

Ahora, repasamos todos los tickets que podemos recordar y lo estimamos. Entonces algunos tickets tendrán más Interés de la Deuda Técnica, otros tendrán menos, algunos consistirán en Interés de la Deuda Técnica debido a errores o situaciones de emergencia como interrupciones y demás que no estarían ahí si no fuera por la Deuda Técnica. Algunos no tendrán Interés de la Deuda Técnica porque serán nuevas funcionalidades que no se ven afectadas por la Deuda Técnica en absoluto, como un módulo separado, algo que estamos comenzando de nuevo.

Y luego, finalmente, tenemos el Interés de la Deuda Técnica estimado para todo. Y también agregamos etiquetas o tags, como quieras llamarlo, que representan los módulos o componentes a los que están relacionados todos los tickets. Y con esta información, podemos obtener una tabla de este tipo, donde tendríamos nuestros segmentos de código y el esfuerzo, y consecuentemente el Interés etiquetado, el Interés etiquetado promedio asociado con ellos, y para cada segmento de código, podremos calcular el sobrecosto real en esfuerzo, como días por persona o cualquier unidad de esfuerzo que estés utilizando. Lo cual es genial para detectar los puntos críticos reales, como cuánto nos afectó esta etiqueta Y el impacto comercial que tendrá cuando solucionemos esta etiqueta en realidad. Y eso es exactamente lo que queremos, ¿verdad? Porque así es como podemos calcular el ROI.

Luego, el ROI es la métrica de todas para cualquier cambio que queramos priorizar frente a las características comerciales, porque estas también tendrán un ROI. Y luego podemos comparar manzanas con manzanas. Digamos que queremos solucionar el componente authentication y nos llevará cinco días por persona, luego tomamos 14 días por persona del sobrecosto debido a la Deuda Técnica en los últimos, no sé, seis a 12 meses divididos por cinco y obtenemos, ¿qué, 2.8? Así que eso es en realidad una proporción relativamente buena.

Ahora solo unas palabras sobre cómo recopilar el Interés de la Deuda Técnica, porque puede ser engorroso y es bueno tener un algoritmo de trabajo bastante óptimo. Primero que nada, asegúrate de que tu equipo registre el tiempo invertido en los tickets. Luego agrega un campo de estimación sin Deuda Técnica en tu rastreador de problemas para cada problema también conocido como ticket. Y luego, con el equipo, se sientan juntos y completan el campo para los tickets anteriores dentro de un marco de tiempo razonable, siendo el marco de tiempo en el que aún pueden recordar, es como que aún pueden recordar los detalles de los tickets para ellos. Por ejemplo, más allá de seis meses en el pasado, difícilmente esperaría que alguien recuerde algo en detalle. Pero tres meses en el pasado, tal vez. Así que defínelo para ti mismo. Y luego lo más importante es que a partir de ese momento, repitas el ejercicio Por ejemplo, en cada retrospectiva, o incluso mejor, agregando donde el rastreador de problemas lo admita, este campo adicional al diálogo de cierre del problema. Para que cada ingeniero, al cerrar el ticket, simplemente complete este campo, y sí, luego tendrás los datos a tu disposición en todo momento.

Entonces, rápidamente sobre los pros y los contras del Interés de la Deuda Técnica. En primer lugar, también está directamente relacionado con el impacto comercial, lo cual es genial. Luego, uno de los más grandes, ignora la Deuda Técnica que en realidad no está causando ningún problema o no ha estado causando ningún problema en los últimos meses que recordamos o del que tenemos datos. También establece una relación muy clara entre los módulos, componentes u otros segmentos de tu código, y el impacto comercial de la Deuda Técnica en ellos. Lo cual, a su vez, facilita la priorización de la Deuda Técnica dentro del conjunto de Deuda Técnica. Entonces sabes claramente en qué necesitas comenzar a trabajar en ese conjunto.

Entre las desventajas, tendrás que es relativamente engorroso de recopilar y de hecho lo es, pero si me preguntas, definitivamente vale la pena y realmente no es tanto problema. Que sea basado en opiniones, también cuestionablemente una desventaja porque quiero decir que es una desventaja, pero habrá opiniones involucradas en la interpretación de todas las métricas que mencioné anteriormente. Así que probablemente sea un poco más opinativo que todas las estimaciones de las métricas anteriores o a veces tal vez menos.

Y luego, la más grande es que esta métrica se basa en el registro de trabajo, lo que significa que está completamente ciega a lo que no se ha trabajado porque no tenemos data. Todas esas estimaciones, cuánto habría tomado si no hubiera habido deuda técnica, y eso significa que realmente no podemos hacer predicciones sobre el futuro de esas partes del código y el interés de la deuda técnica que se les impondrá. Y, sí, solo podemos conocer estas cosas sobre las partes del código en las que hemos trabajado en. Eso sería todo sobre el interés de la deuda técnica, y ahora podemos concluir cómo usar todas esas métricas, porque en primer lugar, has visto que no hay una métrica definitiva que puedas tomar y medir todo con ella. Entonces, tiene que haber una especie de sinergia entre todas ellas. Y esta es la sinergia que sugiero.

Entonces, en el núcleo de esto estaría el interés de la deuda técnica porque es genial para medir el impacto de ambos tipos de deuda técnica, la deuda técnica continua y de mantenimiento, porque, sí, puedes analizar los data de la forma que desees y siempre tendrás algunos números donde tienes los data registrados. Proporciona una muy buena predicción educada, el interés de la deuda técnica, sobre el impacto de la deuda técnica para las partes del código en las que tienes data de interés de la deuda técnica. Sí, para las que has trabajado porque es una predicción mucho mejor. Entonces, una predicción educada es mucho mejor que solo una estimación. Aquí tienes algunas estadísticas y estimaciones más detalladas, que casi siempre son mejores. Y finalmente, ya mencioné el ROI. Y esta es la única métrica que te dará el ROI. Y luego facilita la priorización cruzada entre los cambios de deuda técnica y las características comerciales en gran medida. Luego agregamos métricas heurísticas a la imagen. Nos dan una buena idea general de la salud de la base de código, independientemente de si trabajamos en ella o no. Luego son útiles para estimar el impacto potencial de la deuda técnica para las partes del código en las que solo planeamos trabajar. Entonces, no tenemos data de interés de la deuda técnica. Luego podemos compararlas con las que tenemos data de interés de la deuda técnica y luego asumir proporcionalmente que el interés de la deuda técnica será más o menos así. Y luego estas métricas son definitivamente indispensables para ganancias automatizadas de calidad que probablemente muchos de ustedes han visto anteriormente, como todas esas cosas que verifican sus solicitudes de fusión o solicitudes de extracción y dicen que no pueden fusionarlas porque algo, como la complejidad ciclomática está mal y luego el código está duplicado y así sucesivamente. Y esto es genial porque entonces no aumentamos la cantidad de deuda técnica y verificamos automáticamente esto. Y finalmente, métricas de segundo nivel. Son geniales porque muestran el impacto de nuestros esfuerzos de eliminación de la deuda técnica a través de tendencias, como la proporción de esfuerzos ad hoc, la proporción de esfuerzos ad hoc disminuye o como, no sé, la estabilidad aumenta y así sucesivamente. Y son generalmente indispensables para monitorear la salud general del equipo y del software y por eso sugiero que cada equipo las rastree. Sí, y eso sería todo lo que tengo que decir sobre la medición de la deuda técnica e interpretar los resultados. Aquí hay una diapositiva con las fuentes, cuando tengas acceso a la presentación. Y con eso, muchas gracias. Aquí tienes cómo puedes contactarme nuevamente y espero con ansias la sección de preguntas y respuestas.