¿Qué es para ti la deuda técnica?

No recuerdo cuando escuché el término “deuda técnica” por primera vez, pero estoy seguro de que debió ser en mis comienzos, me imagino que como a casi todos los que nos dedicamos a programar.

Últimamente este concepto se ha hecho aún más palpable en mi día a día. Diría que por la enorme importancia que tiene, especialmente, en una startup. Y sobre todo en sus primeras etapas, como es el caso.
No sabría decir cuántas veces he discutido con Rodrigo o Javi si tomar o no decisiones que aumentaban nuestra deuda, y es que, como es lógico, tiene un peso importante en casi todas las decisiones técnicas que tomamos a día de hoy en Finizens.

Siendo un equipo pequeño, cada decisión que tomamos tiene un impacto enorme en el futuro del proyecto. Es necesario alinear perfectamente las necesidades de negocio con la implementación técnica, considerando los recursos disponibles y adquiriendo la deuda técnica necesaria para avanzar con rapidez, pero sin que sea un peaje demasiado grande a pagar en algún punto del camino.

Pero, ¿qué es la deuda técnica?

Depende a quién le preguntes, para mi se puede resumir así:

La deuda técnica es el gap entre la solución entregada y la solución ideal.

Sin embargo, cada uno hace su interpretación. Hace poco leí un artículo de Jerónimo titulado ¿Es la deuda técnica un síntoma de mala gestión? en el que algunas cosas me gustaron y en otras discrepo enormemente. Finalmente decidí compartirlo, principalmente porque me parece interesante la reflexión.

Me parece muy acertado decir que para pagar la deuda técnica se requiere de un esfuerzo conjunto por parte de toda la empresa. El equipo técnico debería alinearse con el resto de la empresa, y que así todos entiendan el porqué de inversiones de tiempo aparentemente improductivas.

Por el contrario, me parece un tremendo error, como bien apuntaba Raúl, decir que la deuda técnica es un síntoma de inmadurez por parte de la empresa. Puede que sea así, y puede que no, depende de qué tipo de deuda estemos hablando.

Deuda consciente vs deuda inconsciente

Creo que deberíamos distinguir dos tipos de deuda: consciente e inconsciente.

Deuda consciente:

Es aquella que decidimos adquirir. Todas las cosas que posponemos una vez evaluado el esfuerzo y su recompensa.

Aunque estimar el volumen de cualquier desarrollo sea complejo, este tipo de deuda se podrá cuantificar con mayor o menor nivel de precisión.

Deuda inconsciente:

La mayoría de los casos se resume en una mala solución para el problema que se plantea. Pero también podemos encontrarnos con que es simplemente mal código: acoplado, sin tests, sin guidelines, etc…

En mi experiencia, este tipo de deuda se genera normalmente en equipos en los que solo hay programadores con poca experiencia. Aunque obviamente hay muchos más escenarios que pueden promover este tipo de deuda.

La deuda técnica como recurso

Después de unos años de experiencia y de haber pasado de escribir basuritas como un 🤠 Cowboy™, generando mucha deuda de manera inconsciente, hasta crear software mucho más sostenible, desacoplado y testable (o eso intentamos 😇), entiendo la deuda técnica como un recurso, y como tal, no es bueno ni malo, depende de como se use.

Cada vez que afrontamos cambios en nuestro software surgen multitud de preguntas: ¿Es el momento correcto para abstraer cierta funcionalidad?, ¿Deberíamos hacer el refactor en este momento?, ¿Es momento de cambiar de framework?. En ocasiones las respuestas pueden parecer obvias, pero en otras no podremos estar seguros al 100% de estar tomando la decisión correcta. De nuevo, creo que lo importante es tomar la decisión de un modo consciente.

Como profesionales debemos tener clara y controlada nuestra deuda técnica, usándola con responsabilidad, para evitar así sorpresas desagradables en el curso del proyecto que podrían incluso hacer tambalear el proyecto.