No toda la deuda técnica es mala.
Existe la concepción extendida (y errónea, por cierto) de que la deuda técnica es el resultado de no tener calidad, o de hacer ñapas de diseño.
Pero no tiene nada que ver con esto.
La deuda técnica es una decisión consciente, y una muy importante a nivel estratégico en un proyecto.
En el mundo de la inversión, en el que está inspirado el concepto de deuda técnica, se habla mucho de la deuda buena y la deuda mala.
La deuda mala es aquella que contraemos por la mala gestión de nuestra economía: préstamos personales, tarjetas de crédito…
Es decir, la que usamos para seguir gastando, aún cuando no tenemos.
Por el contrario, la deuda buena es aquella que utilizamos para financiar la compra de un activo (algo que nos va a reportar dividendos) aún cuando no tenemos capital. P.ej., una hipoteca, o créditos para usos específicos.
Por ejemplo, imagina que queremos invertir en la compra de una vivienda, pero no tenemos capital suficiente para comprarla.
Podemos pedir una hipoteca, para comprarla con el capital que tenemos ahora, y empezar cuanto antes a generar rentas.
Esto es lo que se conoce como apalancamiento financiero.
En el plano técnico, es exactamente lo mismo.
Seamos claros.
La deuda mala es aquella derivada de nuestra falta de conocimientos y nuestra ineptitud.
Por hacer las cosas mal sin saberlo.
Así que, como el nombre está bastante pervertido, para diferenciarla de la deuda buena, propongo rebautizar esta última: a partir de ahora la llamaré apalancamiento técnico.
El apalancamiento técnico son aquellas decisiones relacionadas con la tecnología que tomamos en un proyecto, a sabiendas de que no son la solución final, pero que tomamos porque nos van a reportar un beneficio a corto plazo.
Por ejemplo, usamos una base de datos en memoria o una solución no-code en la primera versión de nuestro producto, porque nos permitirá validar antes la hipótesis del modelo de negocio.
O incluso, comenzamos empleando una estrategia de testing con forma de trofeo, con menos tests unitarios y más tests de integración, hasta que el diseño se consolide.
Normalmente optamos apalancarnos con alternativas que presentan unos parámetros de tiempos y costes más beneficiosos ahora que en el futuro, pero a sabiendas de que eso cambiará.
La deuda hay que pagarla.
Cuando validemos la hipótesis y entremos en fase de escalado, esa base de datos en memoria habrá que cambiarla por una que escale.
Cuando se consolide el diseño, habrá que reforzar nuestra estrategia de testing añadiendo una buena base de tests unitarios a la pirámide.
A partir del momento en que los parámetros cambien, será cada vez más caro pagar los intereses de la deuda.
Es lo que también se conoce como el último momento responsable, y como técnicos es nuestra responsabilidad identificarlo lo antes posible, para minimizar costes.
Alguien podría argumentar si operar a estos niveles es responsabilidad de un desarrollador o no.
Aunque es cierto que, dependiendo del contexto, no vamos a estar tomando ciertas decisiones, sí vamos a estar informando a aquellos que las toman.
Y es que, como desarrolladores profesionales, nuestros objetivos son dos:
Por un lado, ser capaces de usar nuestro conocimiento técnico para proponer diferentes alternativas con diferentes opciones de apalancamiento técnico.
Por otra parte, mejorar nuestros conocimientos y habilidades para reducir la deuda mala a su mínima expresión.
Si quieres aprender ambas, te invito a que estudies conmigo.
