El código no es deuda técnica
Tratar el software puramente como “deuda técnica” es cuestionado por quienes sostienen que el código es fundamentalmente un activo que aporta valor al negocio, aunque con costos de mantenimiento y pasivos potenciales. Los comentaristas debaten si es más útil modelar el código como activo, pasivo o capital depreciable, cómo las metáforas de deuda influyen en las decisiones de refactorización y de posponer trabajo, y cuándo se justifican las reescrituras completas. Muchos concluyen que la funcionalidad es el verdadero activo, mientras que la calidad del código, la cobertura de pruebas, los requisitos cambiantes y la carga cognitiva determinan si el valor neto de ese activo supera sus costos a largo plazo.
Código: activo, pasivo o ambos
- Muchos sostienen que el código es, en esencia, un activo: encarna funcionalidad que genera valor para el negocio.
- Otros insisten en que el código se modela de forma más útil como un pasivo: cada línea añade mantenimiento futuro y carga cognitiva.
- Varios concilian ambas posturas diciendo que la funcionalidad es el activo; el código que la realiza es un costo o pasivo que puede superar su valor.
Qué significa realmente “deuda técnica”
- Uso común incorrecto: “deuda técnica” == “mal código.” A varios comentaristas les desagrada esta confusión.
- Marco alternativo: la deuda técnica es la brecha entre la implementación actual y cómo la construirías hoy con conocimiento completo y sin presión de tiempo.
- Otra postura: la deuda técnica es trabajo pospuesto o recortado, mejor descrito como “trabajo diferido” para evitar un exceso de confianza en las estimaciones de costo.
- Algunos argumentan que la metáfora de la “deuda” es defectuosa: el código chapucero se parece más a destruir valor presente que a asumir una obligación.
Métricas, líneas de código y complejidad
- Rechazo fuerte a medir el costo o el valor por líneas de código.
- Más código a menudo se correlaciona con más errores y complejidad, pero menos líneas también puede ser peor si son oscuras o demasiado ingeniosas.
- Énfasis en la carga cognitiva, la claridad y la calidad de la abstracción más que en el tamaño bruto.
Cuándo reescribir o refactorizar
- Las reescrituras completas se describen como de alto riesgo y rara vez justificadas; se prefiere el refactorizado incremental junto con pruebas sólidas.
- Algunos ven “grandes reescrituras” repetirse en bases de código mal probadas, mientras que los sistemas bien probados se sienten como activos y evolucionan con más seguridad.
Contexto: tipo de software y escala del equipo
- Se traza una distinción entre herramientas de sistema relativamente estables y software de negocio de cambio rápido con requisitos cambiantes y equipos rotativos.
- Lo que se siente como “sin deuda técnica” en ámbitos individuales y de pocos cambios a menudo no se generaliza a productos grandes y en evolución.
Analogías contables e inmobiliarias
- Múltiples comparaciones con casas, fábricas y bienes raíces: activos con mantenimiento continuo y depreciación.
- Quienes piensan en términos contables subrayan: el código es un activo; el mantenimiento asociado y los atajos son pasivos, no necesariamente “deuda”.
Otras perspectivas y meta
- Las metáforas incluyen jardines, electrodomésticos de cocina, aviones (peso), dientes y andamios para razonar sobre valor frente a mantenimiento.
- Algunos creen que el término “deuda técnica” se ha vuelto tan sobrecargado que oscurece más de lo que aclara.