Nuestro Mr. Nobody de hoy se empeñó, acertadamente, en animar a su equipo a medir la deuda técnica (te dejo post de 2012 y abajo un vídeo más reciente sobre qué es la deuda técnica), ya sabes, resumidamente, que es un eufemismo sobre el coste, y los intereses a pagar, por hacer mal las cosas, por crear software (o cualquier otro producto) que es muy difícil mantener.
Después de mucho lucharlo, Mr. Nobody consiguió que el equipo dispusiera de un Sonar, una herramienta, que es un clásico, para sacar métricas, indicios, malas prácticas. Sonar es una herramienta muy potente, tanto que mide… centenares de posibles indicios de mala calidad, de deuda técnica.
Listo y funcionando Sonar el debate ahora se focalizó en las dudas, dudas y debates azotamentes sobre aquellos centenares de métricas que sacaba Sonar. ¿Por qué esas métricas de deuda técnica y no otras? ¿Quién había decidido que debían ser esas? Y un debate aún más oscuro, porque poca resolución absolutista tiene… ¿Por qué esos rangos que ofrecen las métricas son los correctos y no otros? Y, cómo suele suceder en estos casos, cómo no, un clásico, es que «Sonar no nos representa» porque… «Es que nuestro caso es especial, somos diferentes«.
Lo raro no es que de una métrica no sepamos el valor absoluto y exacto que debiera ofrecer… lo raro es que exista una métrica cuyo valor sea absoluto e indiscutible. Eso es lo raro.
Pasé muchos años leyendo código buscando deuda técnica…
Durante una larga temporada profesional (los antiguos del blog lo recordarán) me dediqué años a mirar código, su deuda técnica, sus métricas, sus «code smells». Años, muchos años (hasta, de hecho, más allá de las tareas profesionales, un día que nos aburríamos, hace 5 años, estudiamos la calidad de 1000 proyectos GitHub).
Y de aquellos años, y después de leer mucho código, te puedo asegurar que algo que corroboré es que nunca sabremos el porcentaje exacto de «copy paste» que un software debiera tener, no sabemos el número exacto de complejidad ciclomática que un algoritmo debiera tener, no sabemos la cantidad exacta de líneas de código que no debería superar una clase, no lo sabemos, ni, probablemente, lo sabremos.
Si vas a rechazar una métrica, y vas a estar quejándote y cuestionándola constantemente, por no disponer del número exacto, e indiscutible, que debieran ofrecer su resultado… es posible que no uses ninguna métrica.
Las métricas nos sirven para ver tendencias, no para buscar valores absolutos
Pero, dicho lo anterior, que debería ser obvio para cualquiera que haya estudiado un poquito de calidad software, que no sepamos el resultado exacto que una métrica debiera tener no significa que las métricas no sean útiles, porque las usamos por la tendencia que ofrecen sus resultados…
- Que no sepamos el porcentaje exacto de «copy paste» que un software debiera tener no invalida que mucho «copy paste» o, para que te sea más obvio, ya que mucho es ambiguo, que el «copy paste» crezca es… MALO y merma dramáticamente la mantenibilidad software.
- Que no sepamos número exacto de complejidad ciclomática que debiera tener un algoritmo no invalida que mucha complejidad ciclomática, o que crezca, es… MALO y merma dramáticamente la mantenibilidad software.
Y así, sucesivamente, con todas las métricas. Algunas serán más discutibles, pero hay otras, como los dos ejemplos anteriores, y otros tantos, que no ofrecen discusión respecto a que si su valor crece es… MALO (independientemente de que no sepamos el número absoluto que debieran ofrecer).
Déjate de excusas
Si una métrica de deuda técnica da 33 y te pones a discutir si debiera ser 33 o no… no has entendido de qué va esto. Preocúpate de que mañana no sea 45, y pasado 178. Y sé consciente de que valores altos son malos, aunque no sepamos el umbral exacto en el que un valor deja de ser normal para pasar a ser malo.
¿Qué Sonar saca muchas métricas? Sí, pero en vez de entrar en el debate eterno de investigar las n-mil métricas sé práctico, empieza por mínimos poco cuestionables desde la más profunda historia de la programación, porque sólo necesitas (va pos de hace 6 años) dos métricas para hacerte una idea de la deuda técnica: complejidad ciclomática y copy paste (¿Por qué copy pastear código es malo? (versión remasterizada for dummies)).
Más y mejor…
Y de aquella época en la que me dediqué años a leer código de n empresas, buscando deuda técnica y code smells, te dejo, recomiendo, que te leas, aunque tenga unos 6 años de antigüedad lo siguiente…
- Cómo interpretar métricas de calidad software: entendiendo el cuadro de mando de Sonar (1/3)
- Cómo interpretar métricas de calidad software: entendiendo el cuadro de mando de Sonar (2/3)
- Cómo interpretar métricas de calidad software: entendiendo el cuadro de mando de Sonar (3/3)
- Mide tu deuda técnica… ¡en 5 min! (post de 2016)
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024