En una planificación, “esto es deuda técnica” puede cerrar la conversación antes de que empiece. La etiqueta no indica qué conducta del sistema preocupa, a quién afecta ni qué decisión se necesita. También puede mezclar una limitación de diseño con trabajo rutinario, una preferencia de estilo o una hipótesis no comprobada. Para priorizar, primero hay que traducir la etiqueta en una observación que se pueda discutir.
Describir el obstáculo sin metáforas
Martin Fowler presenta la deuda técnica como una metáfora para pensar en deficiencias de calidad interna que hacen más difícil modificar o extender un sistema. El artículo relaciona el esfuerzo adicional de cambio con el “interés” de esa metáfora y también señala que las estimaciones de estos costos no son objetivas ni necesariamente precisas (Technical Debt). La metáfora puede ayudar a hablar de consecuencias, pero no convierte una impresión en un monto ni en un pronóstico verificable.
Como criterio de trabajo, registre el comportamiento concreto: qué cambio resulta difícil, qué parte del diseño está involucrada, qué evidencia se observó y en qué condiciones. Separe hechos —por ejemplo, una dependencia que exige coordinar varias modificaciones— de hipótesis, como atribuir esa coordinación a una decisión histórica específica. Esta separación permite buscar la causa en vez de asignar una explicación por intuición.
Ejemplo hipotético: un equipo nota que una regla de validación se modifica en varios módulos cada vez que cambia una política. Puede registrar el cambio solicitado, los puntos que tuvieron que revisarse y el riesgo de divergencia observado. No necesita afirmar un ahorro futuro ni asumir que una reescritura completa resolverá el problema.
Distinguir tipos de trabajo
No toda tarea incómoda es deuda técnica. El libro de SRE de Google define toil como trabajo ligado a operar un servicio que tiende a ser manual, repetitivo, automatizable, táctico, sin valor duradero y que crece linealmente con el servicio; aclara que no todas las características tienen que aparecer a la vez (Eliminating Toil). Esa definición describe una categoría de trabajo operativo, no una etiqueta alternativa para toda deficiencia de diseño.
Una actividad puede requerir esfuerzo manual sin ser toil si aporta una mejora permanente o exige juicio nuevo. A la inversa, una tarea operativa repetida puede ser candidata a automatización sin que exista una deuda arquitectónica. Diferenciarlas ayuda a escoger una respuesta: cambiar una estructura de código, automatizar un procedimiento y mejorar una instrucción operativa son intervenciones distintas.
Comparar alternativas con evidencia
Una ficha de decisión puede reunir la señal, las consecuencias observables, las áreas afectadas, las opciones y las incógnitas. Las alternativas pueden incluir corregir una parte, reducir el alcance, automatizar un paso, aceptar temporalmente la limitación con una condición o investigar antes de actuar. No se trata de completar una lista fija; la opción debe corresponder a la causa que se haya comprobado.
Como criterio de trabajo, valore cualitativamente qué cambio desbloquea, qué riesgo introduce y qué otras tareas requiere. Si se propone posponerlo, registre qué evento haría revisar esa decisión. Si se propone intervenir, acote el resultado que se espera observar y quién verificará que la intervención resolvió el problema descrito. Evite asignar puntajes aparentando precisión cuando los datos no los sostienen.
Priorizar no significa convertir toda fricción en una iniciativa de refactorización. Una parte estable del sistema quizá no justifique una intervención inmediata; una zona que cambia con frecuencia puede merecer atención si existe evidencia de obstáculos repetidos. Esa comparación es una hipótesis local que se debe contrastar con el trabajo y los riesgos del equipo, no una regla universal derivada de la metáfora.
Evitar que la deuda se vuelva argumento circular
Una afirmación como “hay que reescribir porque el código es viejo” no identifica el mecanismo ni prueba que la alternativa propuesta sea mejor. La edad, el lenguaje o la forma del código pueden motivar una inspección, pero no demuestran por sí mismos una consecuencia. Registre la tarea afectada, el comportamiento reproducible y los supuestos que aún requieren validación.
Fowler también advierte que, como no es posible medir la productividad con objetividad, estos costos no son objetivamente medibles y la precisión de las estimaciones suele ser baja. Por ello, una estimación debe explicitar su incertidumbre. No extrapole una observación de un módulo a todo el producto ni presente un ejemplo ilustrativo como resultado de un equipo real.
Registrar una decisión revisable
Un registro breve puede contener: descripción del obstáculo, evidencia, consecuencia potencial, opciones descartadas y motivo, decisión actual, responsable y condición de revisión. Si el trabajo se pospone, anote qué señales vigilar; si se actúa, defina cómo observar si la intervención cambió la situación. Mantener el registro permite revisar el razonamiento cuando cambie el contexto, sin tratar la etiqueta como un mandato permanente.
Qué no cubre este artículo
La nota no asigna valor monetario a la deuda, no estima retornos ni recomienda reescrituras. La priorización depende del sistema, la evidencia disponible, las obligaciones y la capacidad del equipo para asumir cada alternativa.
