Deuda técnica sin quiebra: tu código siempre puede ser peor

Por qué la metáfora del barco que se hunde te está engañando

En 2022, la deuda técnica acumulada en el software empresarial de Estados Unidos rondaba los US$1,52 billones, según datos recogidos por Forbes a partir de cálculos del sector. Es una cifra que crece cada año y, aun así, los fundadores siguen usando una metáfora que impide verla como realmente es: «vamos camino del naufragio».

Zach Kehs, ex Software Development Engineer en Amazon, lo explica con crudeza en su blog personal: el barco nunca toca fondo. No hay un punto de quiebra en el que el software «colapsa» y obliga a hacer algo. Lo que existe es una pendiente sin fin de degradación, y son los negocios —no los repositorios— los que se hunden primero.

La distinción importa porque cambia las decisiones que tomas como founder: si crees que existe un «reset» automático, aplazas la deuda. Si entiendes que no lo hay, la pagas mientras aún es viable.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Lo que Kehs vio dentro de Amazon

Recién salido de la universidad, Kehs aterrizó en un equipo que procesaba pedidos. En teoría, una tarea simple: escribir en bases de datos y orquestar llamadas a servicios de otros equipos. La estimación interna era que bastaba con dos docenas de ingenieros fuertes para mantenerlo.

En la práctica, la organización tenía cientos de personas. El sistema se había vuelto imposible de aprender, con «cementerios encantandos» de código que nadie se atrevía a tocar, reglas de negocio documentadas en archivos que llevaban años sin actualizarse y dependencias entre equipos donde leer el código ajeno era complicado. Cada vez que algo fallaba, las páginas de guardia avisaban — y la reacción era parchear, nunca simplificar.

Cada dos o tres años llegaba un nuevo senior engineer o manager con la misma conclusión: «esto está mal». Se aprobaban re-arquitecturas, se sumaban más ingenieros, se trabajaba con información incompleta porque nadie podía estudiar años de historia técnica a tiempo. El resultado, siempre el mismo: el intento de migración quedaba semi-incorporado al sistema, el senior se llevaba su ascenso y la siguiente camada repetía el ciclo.

Tres ideas que cambian cómo ves la deuda técnica

1. El código no tiene un «suelo» físico

Un edificio colapsa si le añades pisos infinitamente. Un barco se hunde cuando el casco cede. El software no tiene análogo: puedes seguir añadiendo capas de indirección, abstracciones inútiles y rendimiento mediocre sin que nada «se caiga» de forma abrupta. Los cambios que rompen de verdad se revierten rápido, pero los miles de cambios previos que degradaron el sistema — esos se quedan.

2. La empresa muere antes que el código

Una compañía con caja fuerte como Amazon aguanta largos periodos de deterioro interno antes de que afecte al balance. Una empresa cuyo modelo depende más de la calidad del software tiene al competidor esperando a que tu sistema te falle. En ambos casos, la organización se hunde antes que el código — y para entonces, reescribir es inviable.

3. La deuda técnica no tiene bancarrota

La deuda financiera tiene un punto final: la quiebra, una limpieza de tabla. En software, el equivalente — reescribir todo desde cero — rara vez es una opción real. Lo más parecido que tiene un gigante como Amazon es un «canal lateral»: un equipo nuevo construye un sistema paralelo minimalista para un caso de uso nuevo. El sistema viejo sigue vivo, manteniéndose, complicando cada decisión arquitectónica futura.

Cómo lo están viviendo otras empresas

No todo el sector navega igual. Optum Digital (antes Rally Health), con más de 700 ingenieros y cientos de microservicios, hizo pública hace un par de años la metodología que usan para no caer en ese ciclo, según reportó InfoQ: el llamado Technology Capability Plan (TCP).

La idea central: comunidades de ingeniería proponen, de abajo hacia arriba, planes para pagar deuda técnica en horizontes de tres años, marcando el estado de cada tecnología (planificada, en desuso, en migración, en uso, a eliminar). A partir de ahí, la dirección asigna un puntaje de riesgo numérico que aparece en el balanced scorecard corporativo — el mismo tablero que miran los ejecutivos para tomar decisiones. Cuando un product manager pide tres features y el engineering manager responde que el equipo está pagando deuda crítica, el TCP transforma la negociación en algo respaldado por la empresa entera, no en un forcejeo personal.

La moraleja para una startup más pequeña: no necesitas formalizar un TCP para aplicar el principio. Lo que importa es que exista un registro compartido de deuda técnica, que tenga un puntaje visible y que se negocie trimestralmente con producto, en lugar de esperar a una caída para reaccionar.

En el espectro opuesto, el enfoque de microservicios, analizado por TechTarget, busca otra cosa: limitar el radio de explosión de la deuda. Un monolito maltrecho sin esperanza de rescate es la pesadilla clásica. Si la deuda vive en servicios pequeños e independientes, existe la opción de reescribir solo uno de ellos sin tirar el resto. Eso no elimina la deuda, pero deja una válvula de escape real.

Qué significa esto para tu startup

Si Kehs tiene razón (y los números de deuda acumulada en la industria le dan la razón), el peor escenario no es una noche en la que tu software colapsa. Es un trimestre silencioso en el que la velocity de tu equipo baja y nadie detecta por qué — hasta que alguien detecta la caída.

Tres acciones concretas que puedes implementar esta semana

Mide la deuda con un número, no con una sensación. Reserva un porcentaje fijo del roadmap (algunas organizaciones destinan más del 20% de capacidad de ingeniería, según datos de Forbes) a pagar deuda rastreada. Sin métrica, la conversación con producto se pierde en opiniones.
Audita el código que nadie quiere tocar. Pide a tres engineers que nombren los archivos o servicios que evitan modificar. Esa lista es, casi con seguridad, tu mapa de deuda. Pónle fecha y dueño a cada ítem.
Diseña con la idea de «canales laterales». Aunque hoy seas un monolito, mantén la frontera de cada módulo lo más limpia posible para que, si un día toca reescribir, no signifique reescribir todo. Esto encarece un poco la decisión inicial, pero es mucho más barato que la bancarrota técnica que no existe.

El barco no va a tocar fondo nunca. La empresa, si no haces algo, sí.