Deuda técnica: qué es y cuánto cuesta
Qué es la deuda técnica
La deuda técnica es el trabajo pendiente que deja un software cuando se construye o se mantiene tomando atajos: código que nadie documentó, parches sobre parches, dependencias sin actualizar o una tecnología que ya no tiene soporte. Como una deuda financiera, permite avanzar más rápido hoy a cambio de pagar intereses después. Los intereses son el tiempo extra que cuesta cada cambio y el riesgo de que algo se rompa.
No toda la deuda técnica es un error. A veces es una decisión consciente, por ejemplo lanzar una primera versión antes. El problema aparece cuando nadie la registra ni planifica pagarla.
Ejemplos de deuda técnica
- Una aplicación de escritorio antigua que sostiene la facturación y que solo una persona sabe modificar.
- Reglas de precio repartidas entre formularios, informes y macros, sin documentar.
- Una integración manual con el ERP que funciona a base de exportar e importar ficheros.
- Código copiado en varios sitios, de modo que un cambio hay que hacerlo cinco veces.
- Ausencia de pruebas automáticas, que obliga a probar a mano cada actualización.
- Una base de datos sin claves ni validaciones, con duplicados y campos vacíos.
Cuánto cuesta la deuda técnica
El coste rara vez aparece en una factura. Se nota en otras cosas: los cambios pequeños tardan semanas, cada actualización provoca errores en otra parte, el negocio no puede integrar sistemas nuevos y el conocimiento depende de personas concretas. Cuando la tecnología pierde soporte, se suma el riesgo de seguridad y de continuidad.
Cómo reducir la deuda técnica
- Hacer inventario: qué módulos existen, quién los usa, qué reglas contienen y con qué se integran.
- Priorizar por riesgo e impacto, no por antigüedad.
- Reservar tiempo en cada ciclo de desarrollo para pagar deuda, igual que se reserva para funcionalidades.
- Añadir pruebas antes de tocar las partes críticas.
- Modernizar por fases cuando el sistema es demasiado crítico para sustituirlo de golpe.
Cuándo hay que pagar la deuda técnica
Llega un punto en que mantener el sistema cuesta más que modernizarlo: cuando cada cambio es un riesgo, cuando la tecnología ya no tiene soporte o cuando bloquea integraciones que el negocio necesita. Entonces la pregunta pasa a ser si refactorizar por partes o reescribir. La respuesta depende de cuánto valor tienen las reglas de negocio que contiene el sistema y de si se pueden extraer sin parar la operación.
Deuda técnica y modernización en DPI
Las guías de DPI sobre migración de Visual FoxPro y de Microsoft Access a .NET tratan este problema: aplicaciones que concentran años de reglas de negocio y conocimiento sin documentar, y que hay que modernizar por fases sin detener la operación. El desarrollo a medida de DPI cubre el diseño, la integración y la puesta en producción del sistema nuevo.