La deuda técnica es, por definición, el costo asociado a rehacer las cosas cuando las implementaste a la rápida o sin considerar un tiempo para poder refactorizar el código que resuelve un requerimiento o una mejora. Es decir, robar tiempo al futuro.
El problema de la deuda técnica radica en que cada cambio que se ha postpuesto por las urgencias o por no contar con la política o cultura de la mejora continua o LEAN (un poco información), lo que imposibilita sustentar una plataforma o código a lo largo del tiempo, reduciendo la capacidad de acción de los programadores actuales y futuros.
La mejora continua de código es una respuesta fácil y rápida para reducir la deuda técnica, ya que este proceso (escribe, revisa, mejora), ayuda a revisar los pasos dados en la actual fase de desarrollo e invita a mejorar el producto en el siguiente lanzamiento.
La deuda técnica también es un proceso de equipo, ya que las mejoras en el código debe ser trabajo transversal a todos los integrantes del proceso de creación de software. No basta con tener un especialista de software (o arquitecto) que este revisando el código, si los programadores siguen generando código que podría solucionar problemas, pero que en el futuro contribuirá a aumentar los puntos de fallos del código.
Jugando a ser boy-scouts
Este concepto lo he rescatado de varios escritos donde he leído este concepto: ser un boy-scout. Robert Baden, fundador del movimiento acuño la frase:
“El scout deja el mundo mejor de como lo encontró”
Lo que he transmitido a los integrantes de mi equipo es que dejen documentada las funciones que no posean documentación, borren las funciones que ya no sirvem eliminen código comentado (no así los comentarios) y evalúen refactorizar algunas condicionales en caso de ser necesario.
Cada pequeño incremento hace que se reduzca el tiempo de mantención a futuro ya que alguien realizó el trabajo de dejar limpio el código y revisó que el contenido se ajustara las pautas actuales de desarrollo.
Y cómo vamos midiendo
Como experiencia personal, en mi actual trabajo solicité implementar jenkins para hacer un proceso de informe de calidad del código con el fin de ir estimando la deuda técnica y su evolución en el tiempo. El código fuente está en PHP y uso cpd, phpmd, phpdepend y phploc para obtener las métricas del proyecto.
Al inicio del proceso, se registró más de 24 mil problemas de diverso orden y lentamente hemos ido reduciendo la cantidad de errores de estilo y copiado de código hasta llegar a 6 mil errores en forma sistemática.
Claro está, hay problemas que radican más en lo profundo, como el código copiado y pegado (cpd), el cual conlleva más tiempo que una corrección de estilos (más de 120 caracteres en la misma línea).
El proceso ha sido edificante en el equipo ya que esto nos brinda más seguridad a la hora de abarcar el código y nos empodera a hacer cambios con más fácilidad a futuro, resultando en las nuevas implementaciones de mayor calidad que las pasadas.