En el vídeo que propusimos ayer Evolución de la calidad software, del proceso al producto, Javier Garzás habla sobre la deuda técnica. Así que hoy tocaba retomar el tema: Deuda técnica ¿qué es? Buscando posibles definiciones, una de las más acertadas es la de la wikipedia, en su versión inglesa, aunque la versión en español es también es bastante interesante:
La deuda técnica es un eufemismo tecnológico que hace referencia a las consecuencias de un desarrollo apresurado de software o un despliegue descuidado de hardware.
Yo me quedo sobre todo con la primera parte de la definición, eufemismo tecnológico para referirse a las consecuencias de un desarrollo apresurado de software. Yo diría inacabado o mal hecho, ya sea por partir de un mal diseño, por un desarrollo apresurado por plazos inferiores a los necesarios, falto de análisis, o simplemente con errores por no aplicar patrones ni buenas prácticas.
El término deuda técnica viene de una metáfora de Ward Cunningham que describió como hacer las cosas rápido y mal va generando, con mecanismos propios de las burbujas financieras, una deuda similar a nivel técnico.
De todos modos, la deuda técnica no siempre es sinónimo de una chapuza. En ocasiones, esta deuda es un compromiso para satisfacer unos requisitos y cumplir con una entrega pactada, convirtiéndose en lo que algunos llaman deuda técnica intencionada.
Lo importante de esta deuda técnica intencionada es documentarla y gestionarla. En un momento dado podemos hacer un desarrollo de un cierto modo, que puede no ser el mejor modo de hacerlo, y que sabemos que no es el mejor modo, pero que a cambio nos va a permitir entregar valor al negocio. Esto es muy importante. Cuando estamos desarrollando aplicaciones, el fin último es dar valor al negocio. Probablemente, si tuviéramos más tiempo para terminar el desarrollo, el código generado sería de mayor calidad. Pero por otro lado, poner una nueva funcionalidad en producción antes que la competencia, puede ser algo importante para nuestra compañía. O, poniendo esa funcionalidad antes en producción, podemos ver si funciona o no, y posteriormente dedicar más tiempo a eliminar esa deuda técnica, o simplemente olvidarnos de esa nueva funcionalidad, porque hemos visto al ponerla en producción que nuestros clientes no la utilizan.
Es muy importante documentar la deuda técnica. Cuando en un desarrollo sabemos que hay algo que debemos revisar, mejorar y refactorizar, esta deuda técnica debe estar documentada, para que los responsables de los equipos puedan tomar las decisiones oportunas sobre cómo y cuando ir quitándonos esa deuda.
Algunas herramientas nos ayudan a gestionar la deuda técnica, dándonos información que permitirá tomar decisiones. SonarQube, por ejemplo, nos va a dar cierta información sobre nuestra deuda técnica, en base al análisis estático de código, y nos dará estimaciones sobre cuanto nos costaría refactorizar el código para eliminar esa deuda.
Pero lo que SonarQube no nos podrá decir es que en un cierto momento se tomó una decisión, a nivel de arquitectura, por ejemplo, inapropiada, que también ha generado una cierta deuda técnica. Esta debe estar documentada y ser conocida por el equipo, y por los responsables de los equipos. Sólo así se podrá gestionar adecuadamente la deuda técnica.
1 comentario en «Deuda técnica ¿qué es?»