Es un hecho que la deuda técnica es un problema tecnológico que limita la evolución y desempeño de un producto de software, pero antes arranquemos por las bases.

¿Qué es la deuda técnica?, mucho se habla de este término pero poco se sabe de definiciones, encontramos una interesante de la Universidad Carnegie Mellon en el libro Managing Technical Debt: Reducing Friction in Software Development que nos dice “La deuda técnica en sistemas, diseños o implementaciones intensivas en software son construcciones convenientes en el corto plazo, pero que establecen un contexto técnico que puede hacer que a futuro realizar un cambio sea más costoso o imposible“, acompañan esto con una segunda descripción “La deuda técnica es un pasivo contingente cuyo impacto se limita a las cualidades internas del sistema, principalmente pero sin limitarse a mantenibilidad y evolución“.

Con la definición anterior se rompe el estereotipo “son cosas que no se hicieron” por el que normalmente es confundido, no se tiene deuda técnica si se recortó alguna funcionalidad o hay retrasos en el desarrollo, se tiene deuda cuando requiere el “pago de interés”, no todo trabajo incompleto es deuda.

Ya sabemos qué es, pero ¿por qué debería preocuparme de eso ahora?. El punto clave allí es que precisamente como es a largo plazo el efecto de no pagar la deuda, muchas personas no piensan en pagarlo a tiempo o inclusive, piensan en dejarle el problema a la siguiente persona que puedes ser tú, lo cuál está mal desde el punto de vista del profesionalismo pero también a nivel de mindset.

Veamos el efecto con la siguiente analogía “andar en un carro descompuesto”:

Has comprado un carro de segunda, con una “buena calidad”, el carro es capaz de llegar del punto de inicio al punto final sin problema. Si el carro tuviera una “mala calidad” y no le hiciéramos ninguna revisión porque el carro “anda”, seguramente también podríamos llegar del punto verde al rojo, pero ¿qué pasaría si le pedimos a ese carro que vaya al siguiente punto?, seguramente el carro con falta de mantenimiento comenzaría a cobrarnos esa deuda en forma de varadas, reparaciones impagables como un cambio de motor, o inclusive pérdida total por un accidente.

Esto se parece mucho a la forma en que vemos a un producto/canal digital, es también un vehículo que nos permite llegar de un punto A a un punto B aunque aquí se llaman objetivos/OKR/KPI, el “anda” es similar a “el producto está vendiendo”, y si forzamos al software a cumplir nuevos objetivos cuando no se le ha hecho mantenimiento o no se ha pagado nada de la deuda, llegará el momento en que paguemos forzosamente las consecuencias con un producto que fue vulnerado en seguridad, que tiene insatisfechos a los clientes o ponen en riesgo la reputación de una organización de más de un centenar de años.

Muchas veces no somos consientes siquiera que tenemos deuda técnica y nos vamos con una versión errada de entregar valor == liberar nuevas funcionalidades, desconociendo que tener un producto con buenos atributos de calidad también es de altísimo valor para el cliente. Normalmente este tipo de pensamientos apuntan a la rapidez y no a la agilidad, lo que nos lleva a que la deuda sea tan grande que la única forma de repararla sea pagarla con una “parada técnica”, que de por sí es una herramienta peligrosa.

Si tienes una deuda en la tarjeta de crédito y no la pagas mes a mes, cuando se te acumule vas a tener que hacer un préstamo para pagarla, lo cual financieramente es más complicado por que ya no tienes una deuda sino 2 deudas pagando mayor interés. En software es algo parecido, reconoce y documenta tus deudas, trabájalas sprint tras sprint haciendo refactor continuo, no las dejes acumular por que te saldrá más caro.

Las estrategias para ir pagando deuda técnica son variadas, puede hablarse de “desacoplamiento digital”, “eliminar silos”, “hacer historias de pago de deuda técnica”, entre otras soluciones, pero realmente considero que todo depende del mindset, sin esto cualquier estrategia que se proponga será insuficiente y podría fallar. No se trata de que me impongan pagar deuda técnica o que “pago deuda técnica o desarrollo”, no es ni lo uno ni lo otro, tampoco una conmutación prolongada entre ambos, se trata más de ser consiente y en cada cosa que tengas que hacer, actuar siempre en consecuencia.

Existe el concepto de falsos dilemas que debate la forma de creer que solo es posible una cosa o la otra (como o desarrollar o pagar deuda técnica), doy aquí unos ejemplos que he encontrado en mi vida:

  • ¿Ser un crack o tener una buena actitud?

  • ¿Con nosotros o con ellos?

  • ¿Rápido o con calidad?

  • ¿Me dedico a programar o a enseñar?

  • ¿Me dedico a aprender o a enseñar?

  • ¿Le entregamos valor al cliente o aseguramos calidad?

  • ¿Hacemos lo nuevo o corregimos lo viejo?

  • ¿Entregamos toda la aplicación o nada?

  • ¿Estudio y trabajo?

  • ¿Aprendo o hago?

  • ¿Estudio para el primer parcial o para el segundo?

En alguna de estas resulta intuitivo ver, que lo uno no pelea con lo otro, así que los y las invito a mejorar la calidad del software pensando siempre en pagar deuda en todo lo que hagan.

Referencias:

  • https://learning.oreilly.com/library/view/technical-debt-might/53863MIT60123/
  • https://learning.oreilly.com/library/view/managing-technical-debt/9780135646052/glossary.xhtml