La conversación comenzó con todos explicando cómo definen la «deuda técnica», y la definición de todos giraba en torno a la «fricción» en el proceso de desarrollo.
«La deuda técnica es todo lo que crea fricción entre el promotor y la entrega de su trabajo», dijo Goulet. Eso podría significar que su entorno de desarrollo se levante rápidamente. Puede ser que no tengas pruebas. De hecho, solemos definirlo como cualquier cosa que impide a un desarrollador estar completamente en flujo y ser productivo».
Pasqua añadió: «Miramos las cosas que ralentizan a los ingenieros y reducen la calidad».
Rob estaba de acuerdo con esas definiciones. También dijo: «Estas cosas a menudo son notadas primero por los ingenieros, pero los problemas están más en el área de $0027muerte por 1.000 cortes de papel$0027 y no un ingeniero individual diciendo, $0027Oh sí, arreglaré todo eso ahora mismo$0027. Pero si miras estos problemas desde un nivel ligeramente superior, con suerte, tienes el tipo de métrica y datos para poder decir: «Espera un segundo, cada equipo está haciendo esto y los está ralentizando». Y como un todo, se suma. Así que como organización, hay una necesidad de invertir».
En resumen, la deuda técnica podría ciertamente basarse en códigos, pero también podría significar una falta de automatización, una falta de observabilidad o una falta de contexto. Rob incluso incluyó en esa lista la «carga cognitiva», que a menudo se debe a la complejidad del código (o a requisitos vagos, en algunos casos) y que se hace visible a través de la demora (en cuanto al tiempo).