La Deuda Técnica es una excelente metáfora (creada por Ward Cunningham) que nos ayuda a pensar sobre algunos problemas del desarrollo de software. Según la metáfora, hacer las cosas rápido y mal nos incrementa las deuda técnica, la cual es similar a la deuda financiera. Al igual que la deuda financiera, la deuda técnica tiene pago de intereses, que vienen en la forma del esfuerzo extra que será necesario hacer en el futuro por una elección rápida y mala de diseño. Podemos decidir seguir pagando el interés, o podemos pagar el capital al hacer un refactor del diseño hacia un diseño mejor. Aunque hay un costo de pagar este capital, nos ahorramos el pago de intereses en el futuro.
Algunos dicen que el código desprolijo que es producido por personas que no conocen buenas prácticas de diseño (son ignorantes en el tema) no debería llamarse "deuda técnica". En este enfoque, la expresión "Deuda Técnica" se reserva para los casos en que las personas toman una decisión consciente de adoptar una estrategia de diseño que no es sustentable a largo plazo, pero que genera beneficios a corto plazo (como ser lograr llegar a una entrega). El punto es que esta deuda nos permite entregar valor antes, pero necesita pagarse lo antes posible.
Para mi, no tiene sentido preguntarnos sobre si una falla en el diseño es (o no es) una deuda técnica. La deuda técnica es una metáfora, por lo que el tema es si esta metáfora nos ayuda a pensar sobre cómo manejar los problemas de diseño, y cómo comunicar este pensamiento. Un beneficio particular de la metáfora de deuda técnica es que resulta muy útil para comunicar conceptos a personas no técnicas.
La metáfora de la deuda funciona bien en el mundo financiero e informático - la diferencia es la naturaleza de la deuda. Un "lio" es una deuda imprudente que resulta en un pago de intereses excesivo, en cantidad o en tiempo. Esta metáfora resulta muy útil para esos proyectos que tienen una base de código con una deuda técnica alta: es más facil discutir con el cliente partiendo de esta metáfora.
La metáfora de la deuda nos ayuda a recordar las elecciones que podemos tomar con las fallas en el diseño. Una deuda prudente para alcanzar una entrega podría no valer la pena pagarla, si los intereses son lo suficientemente pequeños - por ejemplo, si se trata de una parte del código que no se toca muy raramente.
El cuadrante
Entonces, la distinción útil no pasa por endeudarnos o no endeudarnos, sino por si la deuda es prudente o imprudente.
Y hay otra distinción interesante. La deuda puede ser prudente o impreduente, y también hay una diferencia entre una deuda deliberada y otra inadvertida. Una deuda prudente y deliberada es aquella en la que el equipo sabe que está endeudándose, y por lo tanto analiza si los beneficios de una entrega más temprana son mayores al costo de pagar esta deuda. Por otro lado, un equipo que ignora prácticas de diseño está asumiendo una deuda imprudente e inadvertida, ya que ni siquiera se da cuenta del lio en el que se están metiendo.
Una deuda imprudente podría no ser inadvertida. Un equipo podría conocer buenas prácticas de diseño e incluso ser capaz de aplicarlas, y sin embargo decidir ir "rápido y mal" porque creen que no pueden permitirse el tiempo de escribir un código limpio. El objetivo de hacer un buen diseño y escribir código limpio es que podamos ir más rápido.
Hasta ahora discutimos 3 combinaciones. ¿Existe algo como una deuda prudente e inadvertida? Aunque pueda parecer raro, creo que existe: y no sólo es común, sino también es inevitable para los equipos que son excelentes diseñadores.
Un equipo puede entregar un proyecto con software valioso, el cliente esar feliz y el código ser limpio. Pero el equipo podría igualmente no estar contento con el código. Es posible que el equipo sepa que hizo un buen trabajo, y también se de cuenta que había un diseño mejor para la solución.
Es común escuchar esta situación de los mejores desarrolladores. El punto es que cuando estamos programando, también estamos aprendiendo. A veces, para comprender cuál hubiera sido el mejor diseño es necesario que pasemos todo un año programando en el mismo proyecto. Quizás deberíamos planificar los proyectos para pasar un año construyendo un sistema que luego tiramos para reconstruir, pero sería un plan bastante dificil de vender. En cambio, en el momento que nos damos cuenta cómo debería haber sido el diseño, también nos damos cuenta de una deuda inadvertida.
En este caso sigue aplicando la decisión de pagar el interés vs. pagar el capital, así que la metáfora sigue siendo útil. Sin embargo, la diferencia es que no se me ocurre una metáfora financiera en la que podamos asumir una deuda financiera que sea prudente e inadvertida. Y es por esto que resulta dificil explicar a los gerentes porqué apareció este tipo de deuda técnica. Para mi este tipo de deuda es inevitable, y debemos saber que ocurrirá. Incluso los mejores equipos van a tener que lidiar con alguna deuda a medida que avanza el proyecto - y ese es otro motivo más para no sobrecargarlo imprudentemente con mal diseño y código desprolijo.
