Definición corta

Desviación entre lo que un sistema hace y lo que el equipo que responde de él sabe explicar. Se contrae cada vez que se acepta un código sin que nadie pueda decir por qué está escrito así, y se devuelve en tiempo dedicado a reconstituir una intención que nadie formó.

Definición detallada

La expresión está calcada de la deuda técnica, de la que retoma la mecánica — una ventaja inmediata obtenida a cambio de un coste futuro mayor — cambiando lo que se toma prestado. La deuda técnica se refiere al estado del código; esta se refiere al estado de la cabeza de quienes lo mantienen.

En los artículos de este blog, el término designa la contrapartida del desarrollo asistido: un equipo que mergea código generado, aceptado y parcheado sin que nadie pueda explicarlo obtiene funcionalidad ahora mismo y una incapacidad de diagnóstico más adelante. El pasivo es invisible mientras nada se rompe, ya que la aplicación funciona, las pantallas responden y las pruebas pasan.

El sentido normativo querría una deuda medible y devolvible mediante un trabajo identificado. El uso sobre el terreno no conoce ni contador ni vencimiento: se constata en el momento del incidente, cuando un equipo descubre que ya no sabe por qué todo se derrumba, y su devolución pasa por una relectura que ya nadie tiene tiempo de emprender.

Uso en el ámbito

El término interviene en las reglas de merge — rechazar código que nadie sabe explicar —, en el arbitraje del presupuesto de comprensión por funcionalidad (el contrato, las pruebas, la decisión de arquitectura, los límites conocidos), y en el diagnóstico de un equipo cuyo ritmo de corrección aumenta sin que el producto cambie.

Sinónimos y variantes

"Código no comprendido", "aceptar código que no se explica". Giros vecinos empleados para el mismo pasivo: "un sistema que nunca se ha habitado", "una arquitectura cuyas decisiones no ha tomado nadie".

No confundir con

• Deuda técnica — debilidad de diseño que la empresa ha decidido tratar, y que por ello lleva un coste y un lugar en las prioridades; se devuelve en trabajo de rediseño, mientras que la deuda de comprensión se paga en incapacidad para decidir qué rehacer — y espera una decisión para existir, mientras que esta se contrae en el merge.
• Reconstruibilidad — propiedad de un sistema que un equipo sabría rehacer en otro sitio; es el activo del que esta deuda es el pasivo, y la pregunta "¿sabría reconstruirlo?" es la forma más directa de constatar uno u otro.
• Deuda documental — ausencia o caducidad de los documentos que describen el sistema; un equipo puede tenerlo todo documentado y no entender nada, igual que puede entenderlo todo sin haber escrito nada.
• Bus factor — número de personas cuya marcha volvería inexplotable un sistema; mide el reparto de una comprensión que existe, no su ausencia.
• Legacy — sistema heredado cuyas decisiones se tomaron en otro sitio y antes; la deuda de comprensión se acumula sobre código escrito esta semana.

Ejemplos

"Si un equipo acepta código no comprendido, acepta una deuda de comprensión." — el empleo de referencia, planteado como consecuencia de una regla de merge.

Decenas de pull requests creadas durante la noche por un asistente y mergeadas sin que nadie haya comprobado los impactos: el volumen entregado es pasivo, no adelanto.

Una aplicación que supera los escenarios felices y contiene cientos de decisiones técnicas generadas, aceptadas, parcheadas y luego olvidadas lleva la deuda entera, aunque todavía no haya aparecido ningún defecto.

Ambigüedades / debates

La palabra "deuda" sugiere un importe y un vencimiento que aquí nada permite establecer: ninguna práctica acreditada cifra la desviación entre lo que un sistema hace y lo que un equipo explica de él.

La atribución sigue en discusión: ¿la deuda la lleva quien hizo el merge, o el equipo que mantiene? El uso elegido aquí la sitúa en el equipo, ya que es él quien la devuelve.