Ward Cunningham, wikis y la deuda técnica a lo largo del tiempo

Ward Cunningham: el solucionador de problemas detrás de dos grandes ideas

Ward Cunningham es más conocido por dos frases que escaparon de sus contextos originales y se convirtieron en herramientas cotidianas: “wiki” y “deuda técnica.” Lo que pasa desapercibido es que ninguna de las dos ideas nació como un ejercicio de marca. Ambas fueron respuestas prácticas a problemas recurrentes de los equipos.

Un constructor en las primeras comunidades de software

Cunningham estuvo activo en los círculos tempranos de patrones y agile, contribuyendo a las conversaciones donde se estaba formando el trabajo en equipo moderno en software. Co-creó la primera wiki, construyó herramientas e influyó en prácticas que enfatizaban la retroalimentación, el aprendizaje y la simplicidad.

Su reputación creció menos por teorías grandiosas y más por entregar soluciones pequeñas y funcionales que la gente podía copiar.

Los problemas de equipo que seguía encontrando

En proyectos distintos, Cunningham observó los mismos puntos de fricción: conocimiento atrapado en hilos de correo, decisiones perdidas después de las reuniones y bases de código que cada mes se volvían más difíciles de cambiar.

Los equipos no necesitaban solo “mejor documentación” o “mejor arquitectura”. Necesitaban formas de mantener el entendimiento compartido al día — y de hacer visibles los trade-offs cuando la velocidad de hoy creaba un coste mañana.

Cómo se difundieron las ideas: práctica sobre bombo

La wiki funcionó porque redujo la barrera para contribuir y corregir información. La metáfora de la deuda funcionó porque dio a los equipos una forma respetuosa de hablar sobre costes futuros sin culpar a las personas.

Ambas se expandieron orgánicamente: alguien lo probó, ayudó, y otros lo adaptaron.

Conclusión clave

La línea que une el trabajo de Cunningham es simple: optimizar por el entendimiento compartido y el cambio sostenible. Las herramientas y las metáforas importan cuando ayudan a los equipos a aprender más rápido, alinearse antes y mantener la base de código flexible bajo plazos reales.

Cómo empezó la wiki y qué la hizo nueva

Una wiki es un conjunto de páginas web que cualquiera en un grupo puede crear y editar usando un navegador. En lugar de enviar un documento para aprobación, cambias la propia página — y la página se actualiza inmediatamente para todos.

El avance: “editable por muchos”

Esa idea simple fue la verdadera innovación. Antes de las wikis, “conocimiento compartido” normalmente significaba una de tres cosas:

• Un documento propiedad de un único autor (o un pequeño grupo que hacía de guardián)
• Hilos de correo donde la última respuesta estaba enterrada en el buzón de alguien
• Reuniones donde se tomaban decisiones y luego (lenta y, a menudo, incoherentemente) se redactaban

Una wiki dio la vuelta a ese modelo. Trataba el conocimiento como algo que el equipo mantiene junto, en abierto. Si veías un error, no abrías un ticket para arreglar el documento: lo arreglabas.

La primera wiki: la intención de Cunningham

Ward Cunningham construyó la primera wiki, la WikiWikiWeb, a mediados de los 90 para ayudar a los practicantes de software a compartir patrones, ideas y enfoques de trabajo. Su intención no fue crear una plataforma pulida de publicación. Fue crear una “conversación” que pudiera refinarse con el tiempo, donde pequeñas mejoras se acumularan hasta formar algo sorprendentemente útil.

Los casos de uso iniciales eran pragmáticos: capturar soluciones comunes, clarificar terminología, registrar ejemplos y enlazar temas relacionados para que los lectores pudieran explorar en lugar de buscar entre carpetas.

En qué diferencia de la documentación, el correo y las reuniones

La documentación tradicional suele aspirar a estar terminada y ser autoritativa. Una wiki está cómoda con estar sin terminar — siempre que sea útil ahora.

Los correos son cronológicos; las wikis están organizadas. Las reuniones son efímeras; las wikis dejan un rastro del que los recién llegados pueden aprender sin tener que pedir tiempo en la agenda de nadie.

Esa combinación —edición de baja fricción, enlaces rápidos y propiedad compartida— hizo que las wikis se sintieran menos como “documentación” y más como trabajo en equipo escrito.

Wikis y colaboración: aprendizaje más rápido, menos silos

La idea inicial de la wiki no fue solo “un sitio web que cualquiera puede editar.” Fue un mecanismo simple para convertir lo que la gente sabe en algo que todo el equipo puede usar.

Ese cambio importa porque la mayoría de las ralentizaciones no vienen por la velocidad de tecleo: vienen por la espera: esperar a la persona que recuerda los pasos de despliegue, a quien entiende un caso límite, o a quien sabe por qué se tomó una decisión.

Convertir conocimiento tácito en notas compartidas

Una buena wiki captura hechos pequeños y prácticos mientras siguen frescos: el mensaje de error que viste, la solución temporal que funcionó, la restricción del cliente que reaparece.

Cuando esas notas viven en un lugar único, el aprendizaje se acelera para todos — especialmente para los recién llegados que pueden auto-servirse en lugar de agendar una serie de reuniones “¿puedes explicarme…?”.

Reducir cuellos de botella sin procesos pesados

Las wikis funcionan mejor si se mantienen ligeras: páginas breves, ediciones rápidas, propiedad clara y escritura “suficientemente buena”. El objetivo no es documentación perfecta; es alineamiento.

Una página de dos párrafos que evita un malentendido recurrente vale más que un documento pulido que nadie actualiza.

Ejemplos que dan retorno rápido

Páginas comunes de wiki que reducen silos en el trabajo diario:

• Runbooks: cómo desplegar, revertir, rotar claves y manejar incidentes comunes
• Notas de arquitectura: qué habla con qué, más los “gotchas” que solo aprendes tras romper algo
• Registros de decisiones (ADRs): el problema, las opciones consideradas, la elección y los trade-offs

Con el tiempo, estas páginas se vuelven la memoria del equipo. No reemplazan la conversación: la hacen más corta, específica y fácil de accionar.

Deuda técnica: lo que Cunningham quiso decir (no solo “código feo”)

Ward Cunningham no acuñó “deuda técnica” como un insulto al código feo. Lo usó para describir un trade-off deliberado: tomas un atajo para aprender antes o lanzar antes, sabiendo que debes trabajo extra después.

El significado original: un atajo deliberado con coste

En el encuadre de Cunningham, la deuda se toma a menudo a propósito. Puedes elegir un diseño más simple para obtener feedback real de usuarios, o saltarte una abstracción elegante hasta entender mejor el problema.

La clave es que el atajo crea una obligación futura — no porque el equipo fuera descuidado, sino porque la velocidad y el aprendizaje eran valiosos en ese momento.

Por qué “deuda” y qué implica

Deuda es potente porque implica dos cosas a la vez:

• Obtienes valor inmediato (tiempo, aprendizaje, impulso)
• Pagas intereses si la mantienes demasiado (los cambios se vuelven más lentos, el riesgo sube)

Ese “interés” no es fallo moral; es el coste natural de trabajar sobre una base de código que ya no encaja con lo que sabes.

Pagarla: refactorización y rediseño

El pago mapea bien con la refactorización, mejorar pruebas y rediseñar partes que con el tiempo se vuelven centrales. No se paga reescribiendo todo: se paga eliminando fricciones para que el trabajo futuro siga siendo predecible.

Deuda planificada vs. desorden accidental

La idea de Cunningham más cercana es la deuda planificada: consciente, documentada y revisada.

El desorden accidental es distinto: ownership poco claro, sin pruebas, merges apresurados y diseño descuidado. Llamar a todo eso “deuda” oculta el problema real — falta de toma de decisiones y seguimiento.

Qué acierta la metáfora y dónde engaña

La metáfora de “deuda técnica” caló porque explica una sensación real de los equipos: puedes lanzar antes hoy, pero quizá lo pagues después.

Lo que explica bien

Como la deuda financiera, la deuda técnica tiene intereses. Arreglos rápidos, pruebas faltantes o diseños poco claros a menudo no duelen de inmediato — pero hacen que cada cambio posterior sea más lento, arriesgado y estresante.

También pone el foco en trade-offs y tiempo. A veces asumir deuda es racional: una solución temporal para cumplir un plazo, validar una idea o desbloquear a un cliente. La clave es reconocerlo como una elección, no fingir que está “terminado”.

Y ayuda a los equipos a hablar de repago. Refactorizar, añadir pruebas, simplificar dependencias y mejorar documentación son formas de reducir el interés para que el trabajo futuro sea más barato.

Dónde falla

La metáfora puede volverse moral: “deuda” suena a falta, lo que invita a la culpa (“¿quién lo causó?”) en vez de al aprendizaje (“¿qué presión nos llevó aquí?”).

También puede simplificar demasiado. No todos los desórdenes se comportan como deuda con interés predecible. Algunos problemas son más cercanos a “riesgo desconocido”, “complejidad” o “decisiones de producto faltantes”. Tratarlo todo como deuda puede generar una falsa certeza.

Cómo afecta el lenguaje a las reuniones de planificación

Cuando llamas algo “deuda”, la sala puede oír “ingeniería quiere una sprint de limpieza”. Si en cambio describís el impacto —lanzamientos más lentos, más fallos, incorporación más dura— la gente puede ponderarlo junto a otras metas del negocio.

Directriz

Usa la metáfora para clarificar elecciones: ¿qué ganamos, qué costará y cuándo planeamos pagarlo? No la uses para avergonzar a quien tomó decisiones bajo restricciones reales.

De la metáfora a la práctica: refactorización, pruebas, iteración

La deuda técnica solo sirve si cambia lo que haces el lunes por la mañana. El punto de Cunningham no fue “tu código es malo”, sino “puedes pedir prestado velocidad ahora — si la devuelves deliberadamente”. El repago tiene nombre: refactorización.

Cambios pequeños y frecuentes vencen a las limpiezas grandes

La deuda crece cuando los cambios son raros y arriesgados. Un equipo que espera a una “sprint de limpieza” a menudo descubre que la base de código ha cambiado debajo, haciendo la limpieza cara y políticamente difícil de justificar.

Refactorizaciones pequeñas y frecuentes —hechas junto al trabajo de características— mantienen bajo el coste del cambio. Pagas un poco de interés continuamente en lugar de dejar que se capitalice.

La refactorización es el principal; las pruebas controlan el riesgo

Refactorizar es el “pago principal”: mejorar la estructura sin cambiar el comportamiento. La pega es la confianza.

Las pruebas automatizadas actúan como controles de riesgo: reducen la posibilidad de que tu plan de pago rompa producción.

Una regla práctica: si no puedes refactorizar con seguridad un área, invierte primero en una capa delgada de pruebas alrededor del comportamiento en el que confías.

La iteración permite aprender sin fijar errores

Iterar no es solo lanzar más rápido; es aprender antes. Cuando entregas en trozos pequeños, recibes feedback mientras los cambios siguen siendo baratos. Eso evita “endurecer” prematuramente un diseño que resulta equivocado.

Señales de que es hora de invertir

Fíjate en estas señales en el trabajo diario:

• La entrega se ralentiza aunque el alcance sea similar
• Cambios “frágiles”: ediciones pequeñas que causan fallos sorprendentes
• Bugs recurrentes en los mismos módulos
• Ingenieros que evitan ciertos archivos o componentes

Cuando aparezcan, trata la refactorización y la cobertura de pruebas como trabajo planificado — no como misiones heroicas.

De dónde viene realmente la deuda técnica en el trabajo diario

La deuda técnica rara vez llega con un momento dramático de “elegimos la arquitectura equivocada”. Aparece como pequeños trade-offs hechos bajo presión real — luego se acumula hasta que el equipo se siente más lento, menos confiado y más reactivo.

Sospechosos habituales: velocidad, ambigüedad y partes envejecidas

Una fuente común es un lanzamiento apresurado: un plazo fuerza una solución “suficiente por ahora”, pero ese “ahora” se estira meses.

Otra es el requisito poco claro. Cuando la meta cambia, los equipos suelen construir soluciones flexibles en vez de limpias — porque reconstruir repetidamente parece un desperdicio.

Las dependencias desactualizadas también tiran: librerías, frameworks y servicios evolucionan, y mantenerse al día consume tiempo. Quedarse atrás puede ser racional a corto plazo, pero sube los costes futuros: parches de seguridad más difíciles, integraciones rotas y contratación más complicada cuando el stack parece estancado.

Deriva del diseño: cuando los parches rápidos se vuelven el diseño

Incluso sistemas bien diseñados pueden derivar. Un parche pequeño para un caso límite marca un precedente. Otro parche se apila encima. Con el tiempo, el “diseño real” se convierte en lo que sobrevivió en producción, no en lo que alguien pensó.

Por eso a veces se dice “nadie entiende este módulo”. No es una falla moral: es deriva.

Deuda de conocimiento y deuda de tooling (las que se pasan por alto)

No toda la deuda está en el código.

Deuda de conocimiento crece cuando las decisiones no se capturan: por qué se tomó un atajo, qué riesgos se aceptaron, qué alternativas se descartaron. El siguiente desarrollador no puede pagar lo que no puede ver.

La deuda de tooling es igual de real: builds lentos, tests frágiles, pipelines CI delicados y entornos de desarrollo inconsistentes. Esto crea fricción diaria que fomenta más atajos — alimentando el ciclo.

Si buscas deuda temprano, fíjate en trabajo repetido, creciente “miedo a refactorizar” y tiempo peleando con herramientas en vez de construir funcionalidades.

Priorizando la deuda: reglas prácticas de decisión para equipos

La deuda técnica no es una única “sprint de limpieza”. Es un flujo de trade-offs. Lo difícil es elegir qué revertir primero — sin bloquear la entrega ni dejar que el desorden se acumule.

1) Paga lo que bloquea el cambio (no lo que es feo)

Empieza por la deuda que hace el trabajo diario más lento o arriesgado:

• Áreas que se rompen con frecuencia, requieren heroicidades para desplegar o desencadenan largas cadenas de bugs
• Módulos que nadie quiere tocar porque los cambios son impredecibles
• Partes del producto donde solicitudes pequeñas de usuario se convierten rutinariamente en reescrituras grandes

Una prueba simple: si una pieza de deuda aumenta el tiempo para entregar valor al usuario cada semana, es un préstamo de alto interés.

2) Equilibra valor de usuario vs. mejora interna con “empaquetado”

En lugar de discutir “feature vs. refactor”, júntalos:

• Cuando lanzas una feature en un área frágil, presupuestá tiempo para reducir la deuda local que tocaste
• Vincula la limpieza a un resultado concreto (menos incidentes, despliegues más rápidos, incorporación más sencilla)

Esto mantiene el trabajo interno anclado al impacto de usuario y evita que el trabajo “nuevo” profundice el agujero.

3) Haz la deuda visible de formas ligeras

Los equipos priorizan lo que pueden ver. Mantenlo simple:

• Un registro de deuda en el tracker: título corto, ubicación, impacto y arreglo sugerido
• Etiquetas como deuda, riesgo, compilacion-lenta, dificil-de-probar en issues y PRs
• Notas pequeñas en docs explicando “por qué esto está raro” y qué dirección más segura sería

La visibilidad convierte quejas vagas en opciones accionables.

4) Pon límites: no más deuda nueva sin propietario y plan

A veces tomarás deuda deliberadamente (los plazos existen). Hazlo una decisión controlada:

• Nombra un propietario
• Define el disparador de pago (la próxima release, tras un umbral de métricas, después del despliegue a clientes)
• Captura el plan mínimo: qué se cambiará y qué significa “hecho”

Esto evita que atajos “temporales” se conviertan en arquitectura permanente.

Usar wikis para gestionar la deuda: documentación que realmente ayuda

Una gran razón por la que la deuda técnica vuelve es que los equipos olvidan por qué se tomó una decisión.

Una wiki puede actuar como la “memoria” de la base de código: no solo qué hace el sistema, sino qué trade-offs se aceptaron, qué se pospuso y qué supuestos podrían romperse más adelante.

Cómo una wiki apoya decisiones coherentes en el tiempo

Cuando entran nuevas personas — o un equipo revisita un módulo meses después — una wiki les da el contexto que no es visible en el código. Ese contexto ayuda a tomar decisiones coherentes, para que no “pagues interés” volviendo a aprender las mismas lecciones con bugs, reescrituras o entregas lentas.

La clave es vincular el conocimiento a los momentos en que se tomaron decisiones: releases, incidentes, migraciones y refactors importantes.

Plantillas útiles (simples y repetibles)

Una wiki funciona mejor cuando las páginas siguen unas plantillas ligeras:

• ADRs (Architecture Decision Records): la decisión, alternativas consideradas y consecuencias
• Revisiones de incidentes: qué pasó, factores contribuyentes y seguimientos (incluyendo ítems de deuda)
• Estándares de código: el pequeño conjunto de reglas que evitan trabajo de limpieza recurrente
• Registro de deuda: mejoras intencionalmente pospuestas, con “por qué ahora/por qué no” capturados

Mantén cada página corta. Si necesita una reunión para entenderse, es demasiado larga.

Mantener la docs confiable

La documentación se vuelve dañina cuando está obsoleta. Hábitos pequeños lo previenen:

• Propiedad: cada página tiene un propietario nombrado (equipo o persona)
• Fechas: incluir “Última revisión” y “Próxima revisión”
• Revisión ligera: una comprobación rápida durante la revisión de sprint o sincronía técnica mensual — cinco minutos bastan

Vincular items de trabajo al contexto

Siempre que abras un ticket para “refactorizar X” o “limpiar Y”, enlázalo al ADR, la revisión de incidente o la entrada del registro de deuda relacionada.

Así, cuando alguien pregunte “¿por qué gastamos tiempo en esto?”, la respuesta está a un clic — y futuros cambios son más fáciles porque la intención queda clara.

Comunicar la deuda sin prometer métricas imposibles

La deuda técnica se financia mejor cuando la gente entiende el impacto, no cuando les das una hoja de cálculo de “puntos de deuda”. La metáfora de Cunningham funciona porque traduce trade-offs de ingeniería a una conversación de negocio — así que mantén el mensaje simple, específico y anclado en resultados.

Lidera con declaraciones de impacto (no con precisión fingida)

Evita afirmaciones como “tenemos 37% de deuda” o “este módulo lleva 12 días de retraso”. Describe en su lugar lo que el equipo no puede hacer — o no puede hacer con seguridad — por la deuda.

Ejemplos:

• “Añadir una regla de precios pequeña ahora toma un día entero porque los cambios repercuten en tres servicios.”
• “Los despliegues requieren una lista de verificación manual y dos personas en espera, así que publicamos menos seguido.”
• “Evitamos tocar el flujo de facturación, lo que aumenta la probabilidad de un incidente de alta severidad cuando finalmente debemos hacerlo.”

Usa un pequeño conjunto de señales honestas

Las métricas ayudan, pero solo si las tratas como indicadores, no como pruebas definitivas.

Opciones útiles que muchos equipos pueden medir sin tooling pesado:

• Lead time (idea a producción): la deuda suele alargarlo
• Tasa de fallos en cambios: la deuda aparece como más rollbacks y hotfixes
• Duración de build/test: la deuda enlentece los ciclos de feedback
• Tendencias de defectos: especialmente defectos repetidos en las mismas áreas

Explica el “interés” en términos claros

El interés es el coste adicional que pagas cada vez que trabajas en esa área. Dilo así: “Cada cambio cuesta 2–3 horas adicionales en retrabajo, coordinación o pruebas manuales. Pagar esta deuda reduce ese recargo continuo.”

Informa con historias, luego números

Acompaña un ejemplo corto (qué ralentizó, qué riesgo aumentó) con una métrica de apoyo. Las historias crean claridad; las métricas dan credibilidad — sin pretender medirlo todo exactamente.

Mini manual: aplicar pensamiento Wiki + Deuda a un proyecto

No necesitas una iniciativa a nivel de compañía para beneficiarte de las dos grandes ideas de Ward Cunningham. Ejecuta un ciclo pequeño y repetible en un proyecto: usa una página wiki como memoria compartida y trata la deuda técnica como un trade-off consciente que puedes pagar.

Paso 1: Inventario (30–60 minutos)

Crea una sola página de wiki: “Proyecto X: Registro de Deuda & Aprendizajes.” En una reunión corta, lista los puntos calientes con los que el equipo tropieza.

Concéntrate en dolor recurrente, no en calidad de código abstracta:

• Áreas lentas de cambiar
• Bugs que vuelven
• Tests que la gente evita actualizar
• Preguntas de onboarding que se repiten cada semana

Para cada ítem, añade dos notas: “¿Qué pasa cuando falla?” y “¿Qué trabajo se retrasa?” Esto mantiene la conversación anclada en resultados.

Paso 2: Plan (15 minutos)

Elige 1–3 ítems solamente. Para cada uno, escribe:

• Hecho significa: un estado final concreto (p. ej., “la API tiene pruebas para los casos límite A/B/C”)
• Timebox: 2–10 horas o 1–3 días — lo bastante pequeño para terminar
• Propietario + revisor: para evitar limpiezas a medias

Si necesitas una regla: elige la deuda que más mejore el trabajo de la próxima semana, no una mejora teórica futura.

Paso 3: Hacer el trabajo (durante el desarrollo normal)

Trátalo como trabajo de feature: commits pequeños, pruebas cuando sea posible y una nota corta en la wiki sobre qué cambió y por qué.

Paso 4: Revisar y actualizar la wiki (10 minutos)

Añade una breve sección “Qué aprendimos”: qué te sorprendió, qué llevó más tiempo y qué harás distinto la próxima vez. Luego ajusta la lista y repite el ciclo semanal o quincenalmente.

Nota de tooling: acelerar el ciclo sin perder el rastro

Si tu equipo construye nuevas herramientas internas o prototipos, plataformas como Koder.ai pueden encajar bien en este flujo: puedes usar su modo de planificación basado en chat para capturar suposiciones y decisiones por adelantado, lanzar un slice funcional en React/Go/PostgreSQL (o Flutter) rápidamente, y usar snapshots y rollback para evitar que la experimentación se convierta en deuda accidental y de larga vida. Cuando haga falta, puedes exportar el código fuente y llevar el proyecto a tu repositorio y proceso de revisión habituales.

Usos indebidos comunes de “deuda técnica” (y alternativas mejores)

“La deuda técnica” es una metáfora útil — hasta que se convierte en etiqueta comodín para cualquier cosa molesta. Cuando eso ocurre, los equipos pierden la capacidad de tomar trade-offs claros.

Uso indebido 1: “Deuda técnica” = cualquier código que no me guste

No todo código desordenado es deuda. La deuda es un atajo deliberado tomado para moverse más rápido ahora, con un coste entendido después.

Mejores alternativas:

• Si es confuso: llámalo legibilidad o mantenibilidad
• Si es riesgoso: llámalo fiabilidad o un patrón de defectos
• Si es lento: llámalo trabajo de rendimiento

Uso indebido 2: Tratar la deuda como una limpieza única

Una “pagarla toda” sprint suele fallar porque la semana siguiente se crea nueva deuda. La idea de Cunningham encaja mejor como hábito: pide prestado con cuidado, paga regularmente.

Mejor alternativa: crea un presupuesto continuo de refactorización (arreglos pequeños y frecuentes ligados al trabajo real) en vez de una limpieza de golpe.

Uso indebido 3: Echar la culpa a individuos

La deuda rara vez es culpa de una persona. Plazos, requisitos poco claros, pruebas faltantes y handoffs generan condiciones donde los atajos son racionales.

Mejor alternativa: describe la restricción del sistema (“sin entorno de pruebas”, “propiedad poco clara”, “lanzamientos a la carrera”) y arregla eso primero.

Uso indebido 4: Dejar podrir la documentación (especialmente wikis)

Una wiki obsoleta es peor que no tener wiki: da confianza y difunde supuestos equivocados.

Mejor alternativa: mantén las páginas pequeñas, con propietario y revisables — añade notas de “última verificación”, enlaza a tickets fuente y elimina páginas que no se pueden mantener.

Lista de acciones: qué hacer esta semana

No necesitas una reorganización ni una nueva herramienta para obtener valor del pensamiento “wiki + deuda” de Cunningham. Necesitas unos hábitos ligeros que hagan los trade-offs visibles y repetibles.

1) Empieza un registro de deuda que siga vivo

Crea una página en la wiki de tu equipo llamada Registro de Deuda. Manténla corta y actual.

Para cada entrada, captura:

• Qué duele (síntoma que sienten usuarios/desarrolladores)
• Dónde (repo/módulo/servicio)
• Por qué ahora (qué lo desencadenó)
• Próximo pago más pequeño (paso concreto de menos de un día)
• Propietario + fecha de revisión (no un backlog eterno)

2) Introduce la refactorización en la planificación normal

Añade un presupuesto recurrente dentro de la planificación de sprint/semana (aunque sea pequeño): p. ej., 10–20% de capacidad o una historia de refactor por feature.

Hazlo explícito: “Pagamos interés cada semana; esto es un pago programado.” Vincula las tareas de refactor a un objetivo visible para el usuario cuando sea posible (cambios más rápidos, menos incidentes, tests más sencillos).

3) Estandariza 2–3 plantillas de wiki

La consistencia vence al detalle. Empieza con:

• Registro de decisión (ADR-lite): contexto → decisión → consecuencias
• Página de módulo: propósito → flujos clave → peligros comunes → cómo probar
• Entrada del registro de deuda: los campos anteriores

4) Acordad lenguaje de equipo (para que “deuda” no signifique “todo lo que no me gusta”)

Escribid una breve “Definición de Deuda” en la wiki: qué cuenta, quién puede etiquetarla y cómo se aprueba el repago.

Una regla útil: La deuda es un trade-off consciente con un plan de devolución. Si es simplemente confuso, etiquetadlo como “desconocido”, “bug” o “riesgo de diseño” en su lugar.