DEUDA TECNICA

“Enviar el código por primera vez es como endeudarse. Un poco de deuda acelera el desarrollo
siempre que se pague pronto con una reescritura... El peligro surge cuando la deuda no se
paga. Cada minuto gastado en código no del todo correcto cuenta como interés sobre esa
deuda. Las organizaciones de ingeniería enteras pueden paralizarse bajo la carga de la deuda
de una implementación no consolidada, orientada a objetos o de otro tipo”.
—Ward Cunningham, 1992

la deuda técnica se compone de dos elementos:

La deuda en sí (defectos de diseño iniciales)
El interés asociado a la deuda (esfuerzos extra para implementar nuevas funcionalidades
debido a la complejidad que provocan los defectos de diseño iniciales)
Para pagar o eliminar la deuda, un equipo debe abordar tanto el interés como la deuda al
mismo tiempo. Si un equipo paga solo los intereses, nunca logrará pagar la deuda, ya que
generará nuevos intereses con el tiempo. Como resultado, será difícil para el equipo
implementar funcionalidades y nuevas características en el futuro.
La deuda técnica no es necesariamente "mala"; de hecho, es una parte necesaria e inevitable
del proceso de desarrollo de software, pero se convierte en un problema cuando no se gestiona
correctamente. Eso significa que los equipos deben centrarse en una gestión adecuada para
minimizar los efectos adversos.
Cuando los equipos crean una deuda técnica, siempre requerirá un esfuerzo adicional para
volver a trabajar en el código y pagar esa deuda. La necesidad de volver a trabajar no es
necesariamente negativa. La diferencia entre la deuda técnica que actúa como un beneficio o
un pasivo tiene que ver con la intención.
Cuando la deuda técnica es intencional , todos los miembros del equipo lo saben y el monto es
claro y está bien documentado. Cuando la deuda técnica no es intencional , es posible que los
miembros del equipo no se den cuenta y experimenten problemas de desarrollo sin saber por
qué, lo que perpetúa aún más el problema.

Violación de los principios de diseño del código:

Debido a limitaciones de tiempo u otros factores, su equipo podría decidir violar
deliberadamente los principios de diseño de código al crear código con baja cohesión,
componentes estrechamente acoplados y otros inconvenientes. Estas acciones pueden ser
necesarias para que el proyecto siga avanzando; sin embargo, su equipo debe verlos solo
como compensaciones temporales y corregirlos lo antes posible, para que no causen más
problemas más adelante.
Beneficios de la Deuda Técnica Intencional:
Cuando la deuda técnica se asume y administra intencionalmente, puede beneficiar a un
proyecto de muchas maneras. Al igual que en el mundo financiero, asumir una deuda pequeña
puede ayudar a su equipo a obtener beneficios mucho mayores que la deuda misma, pero solo
si se calcula y hay un plan para pagar la deuda.

Beneficios:
Cumplir con el plazo de comercialización
El período de tiempo de comercialización cubre el tiempo para generar la idea de un producto y
luego diseñarlo, desarrollarlo y lanzarlo. A menudo, un cliente tiene plazos de publicación
estrictos debido a eventos de marketing o demostraciones importantes.
En este tipo de situación, su equipo debe trabajar con rapidez y es posible que deba permitir
fallas menores en el código (que no interrumpen un lanzamiento exitoso) para cumplir con la
fecha límite. Estos problemas luego se convierten en una deuda técnica que su equipo aborda
después del lanzamiento.
Creación de POC y MVP
Si su equipo prepara una Prueba de concepto (POC) o un Producto mínimo viable (MVP) para
un cliente, debe presentar la idea general de cómo implementará la solución. En este caso,
está bien si la calidad del código no es perfecta.
Aquí, entrar en deuda técnica ahorrará tiempo y no hay riesgo de perjudicar el negocio.

INDICADORES:
Para reducir las posibilidades de que su equipo acumule deuda técnica no intencional, esté
atento a los indicadores en cada una de estas áreas: entrega, arquitectura y personas.
INDICADORES DE ENTREGA:
Degradación de la calidad:

 Los problemas de producción son defectos y errores de producción.

 Los problemas de regresión aparecen debido a los efectos secundarios provocados por
un defecto en la funcionalidad anterior. Un equipo realiza pruebas de regresión antes de
lanzar una nueva versión a producción, y la deuda técnica existente influye en la
cantidad de errores que encuentran durante la prueba. Cuando un equipo realiza
cambios en una parte del sistema, la degradación de la calidad conduce a una situación
en la que un defecto o un comportamiento inesperado pueden aparecer repentinamente
en otra parte del sistema.
 Los problemas conocidos son errores que un equipo conoce pero que se consideran no
críticos y adecuados para su publicación. Una lista de problemas conocidos suele ser
una señal de que un equipo tiene una deuda técnica que debe gestionar.
Alto costo de cambio de sistema:

 Si aumenta la cantidad de esfuerzo y tiempo que lleva hacer un nuevo cambio, puede
indicar una deuda técnica.
Incapacidad para experimentar rápidamente.
Un proceso típico de desarrollo de software incluye investigar las posibilidades técnicas y
prepararPicosy POC. Estas actividades a menudo tienen un cronograma limitado, que suele ser
suficiente para que un equipo produzca un resultado deseable. Sin embargo, si se da cuenta de
que su trabajo en picos o POC está acompañado de muchos efectos secundarios, problemas
de implementación y falta de transparencia y legibilidad, esto podría indicar una deuda técnica.
Aumento de las barreras de entrada.
Si encuentra que navegar a través de su código requiere conocimiento experto, podría indicar
una deuda técnica. Si solo uno o dos compañeros de equipo pueden implementar la
funcionalidad (¡alerta de factor bus!) y la curva de aprendizaje para una nueva persona es muy
alta, esté atento a la deuda técnica.
Indicadores de arquitectura
Si es un desarrollador de software o un arquitecto responsable del diseño del sistema, es
posible que note una deuda técnica a través de sus efectos adversos en la facilidad de
integración, reutilización, escalado del sistema, mantenibilidad o calidad de la documentación.

 Difícil de Integrar: Cuando a su equipo le resulta difícil integrar nuevas funciones en el

sistema o realizar una integración de sistema a sistema, podría ser una señal de deuda
técnica. La deuda técnica hace que sea imposible para su equipo no solo implementar
su plan, sino incluso imaginar una forma de llevar a cabo esa integración.
 Difícil de reutilizar: Un diseño de alta calidad tiene bajo acoplamiento y alta cohesión.
Por el contrario, el alto acoplamiento y la baja cohesión son fallas graves del sistema
que dificultan la reutilización de los componentes existentes en el sistema. Si su diseño
es difícil de usar debido a estos factores, es muy probable que se haya acumulado una
deuda técnica.
 Difícil de crecer: Cuando su equipo ve que un sistema no admite el escalado, o si es
difícil aumentar el rendimiento, esto podría ser un indicador de deuda técnica.
 Difícil de apoyar: La deuda técnica también puede causar baja mantenibilidad del
sistema y calidad de la documentación. Cuando la calidad de la documentación solo
cubre algunas áreas de una solución, es una señal alarmante.

INDICADORES DE EQUIPO
Varios problemas del equipo también pueden indicar la necesidad de gestionar la deuda
técnica. Cualquier miembro de su equipo puede ver este tipo de indicadores,
independientemente de su función.
Retrasos: Los retrasos causados por las complejidades del proyecto son un indicador común
de la deuda técnica.
Bajo Nivel de confianza en la estimación del alcance: Si ve que su equipo subestima o
sobreestima el alcance del proyecto, eso podría indicar una deuda técnica.
Desmotivación: Los impactos de la deuda técnica pueden llevar a la desmotivación del
equipo.
Seguimiento de la deuda técnica

 Mantener actualizado el registro de deuda técnica: Un registro de deuda técnica es

un documento compartido de formato libre donde un equipo pone notas sobre la deuda
técnica que identifican. El objetivo de este documento es tener todas las notas en un
solo lugar para que el equipo pueda abordarlas en el futuro.
 Use una acumulación de deuda técnica: Una acumulación de deuda técnica es una
lista de tareas que realiza un equipo al limpiar y clasificar el registro con regularidad.
Después de eso, el equipo coloca una nueva lista de tareas en el sistema de
seguimiento, luego describe y prioriza las tareas.
 Utilizar herramientas técnicas de gestión de deuda: Su equipo puede utilizar
herramientas técnicas de gestión de deuda, incluidas herramientas de control de
calidad, para realizar un seguimiento de los problemas y crear una estrategia de
minimización de deuda.
Las herramientas Quality Gate, como SonarQube, pueden ayudar a su equipo a
visualizar y rastrear:

- El porcentaje de cobertura de la prueba

- El índice de complejidad del código.
- El número de violaciones de reglas.
- Otros indicadores cuantitativos

RECOMENDACIONES PARA DESARROLLADORES:

 Evite los olores de código. Como desarrollador, la contribución más importante que puede
hacer a la gestión de la deuda técnica es evitar los olores de código siguiendo los principios
de código limpio, como Responsabilidad única, Abierto/Cerrado, Sustitución de Liskov,
Segregación de interfaz e Inversión de dependencia (SOLID) y Don' t Repítase (SECO).
 Realizar revisiones del código. La revisión del código puede ayudar a su equipo a identificar
discrepancias en el código y señalar si su equipo sigue los mismos estándares y pautas.
Cuanto antes pueda identificar un problema, más rápido podrá asegurarse de que no
genere ningún problema con su solución.
 Compartir conocimientos. El intercambio efectivo de conocimientos garantiza que todos en
su equipo estén en la misma página. Cuantos más guardianes del conocimiento tenga en
su proyecto, más estable será.
 Utilice herramientas de análisis de código. Varias herramientas de análisis de código
pueden ayudar a su equipo a verificar la confiabilidad, la capacidad de mantenimiento y
otras características del código. Verificar el código manualmente en lugar de usar las
herramientas apropiadas no es un uso eficiente del tiempo y no garantiza que identificará
todas las fallas.
 Utilice pruebas automatizadas. Las pruebas automatizadas pueden ayudar a su equipo a
identificar los problemas que surgen al descuidar los principios de diseño de software. La
unidad de automatización, la interfaz de programación de aplicaciones (API) y las pruebas
de extremo a extremo (E2E) le brindarán a su equipo una retroalimentación rápida que le
permitirá introducir cambios seguros en su solución.