Todo el código es deuda técnica
Plantear “todo el código como deuda técnica” provoca debate sobre si el término se ha estirado más allá de su utilidad o si, por el contrario, resalta de forma útil que cada función y cada línea de código añadidas implican un coste continuo. Los comentaristas revisan la metáfora original de la deuda de Ward Cunningham, la contrastan con la interpretación moderna de “atajo” y argumentan que el código se entiende mejor como un pasivo, un inventario o un activo depreciable cuyo valor debe justificar su mantenimiento y complejidad. Muchos subrayan que el verdadero apalancamiento proviene de menos funciones, bien elegidas, de eliminar agresivamente el código no usado y de involucrar a las partes interesadas del negocio en intercambios explícitos entre velocidad, calidad y flexibilidad a largo plazo.
Alcance de la “deuda técnica”
- Muchos sostienen que el artículo diluye la “deuda técnica” al llamar deuda a todo el código; ven la deuda técnica como atajos específicos o diseños desalineados que generan “intereses” en el trabajo futuro.
- Otros la amplían: cualquier desajuste entre el código actual y el entendimiento o los requisitos actuales, o más en general, cualquier impedimento entre lo que quieres hacer con el sistema y cómo es realmente.
- Hay debate sobre el significado original (retraso de diseño impulsado por el aprendizaje) frente al uso moderno de “sabíamos que estábamos recortando porciones”; algunos lamentan que términos precisos como “deuda técnica” y “refactorización” se hayan difuminado.
El código como pasivo, activo o inventario
- Tema dominante: el código es un pasivo/un coste de mantenimiento. Más código → más que entender, mantener y adaptar; el código eliminado se celebra.
- Contrapunto: el software ejecutable y las funciones útiles son activos; el código es al menos en parte un activo porque permite el cambio y la creación de valor.
- Algunos prefieren analogías como “inventario” o “activo depreciable” en lugar de “deuda” o “pasivo puro”.
Complejidad, funciones y supuestos
- Más funciones y supuestos aumentan la complejidad y la fricción futura, incluso si hoy “funcionan”.
- Varios señalan que la mayoría de los proyectos no eliminan suficiente código ni suficientes funciones; el código obsoleto o sin uso persiste y acumula costes ocultos.
- Una idea recurrente: la buena ingeniería consiste en minimizar supuestos y conceptos, y trabajar dentro de los existentes cuando sea posible.
Calidad, entropía y mantenimiento
- Muchos ven la deuda técnica como una forma de entropía: incluso las decisiones bien intencionadas se acumulan en complejidad a medida que cambian los requisitos, las plataformas y las personas.
- Se hace una distinción entre “mal programar” y buen código que simplemente refleja un entendimiento o unos requisitos desactualizados.
- Las pruebas y las abstracciones también tienen coste; la sobreabstracción (por ejemplo, llevar DRY demasiado lejos) puede ser peor que la duplicación.
Problemas organizativos y de comunicación
- Las partes interesadas del negocio suelen tratar la “deuda técnica” como una molestia puramente técnica; los comentaristas insisten en plantearla en términos de tiempo de salida al mercado, fiabilidad y coste de oportunidad.
- Los incentivos de la gestión favorecen añadir funciones y posponer la limpieza; proponer refactorizaciones o reescrituras es arriesgado y atrae fácilmente la culpa.
Recepción del artículo
- A algunos el titular y la premisa les parecieron clickbait o reductivos; otros apreciaron que provoque reflexión sobre construir en exceso, el crecimiento descontrolado de funciones y el valor de escribir menos código.