Debida tecnica sin fin: por que el codigo no se hunde y siempre puede empeorar

Las metáforas navales no funcionan para describir el estado de una base de código. Zach Kehs argumenta que hablar de un «barco que se hunde» para referirse al endeudamiento técnico crea una sensación de seguridad falsa. Un barco tiene un fondo y un momento concreto en el que se pierde. El software no tiene suelo, ni bancarrota, ni reinicio limpio. Puede seguir degradándose indefinidamente.

Kehs basa su tesis en su experiencia temprana en Amazon como ingeniero de desarrollo de software. El equipo encargado de procesar pedidos parecía necesitar, en teoría, una veintena de ingenieros competentes para mantenerse. En la práctica, la organización contaba con cientos de personas y el sistema había crecido hasta volverse ininteligible. El conocimiento institucional se había corroído y el código se llenaba de «cementerios encantados»: segmentos de lógica heredada que nadie atrevía a tocar por miedo a romper algo crítico. Las reglas de negocio vivían en documentos obsoletos o, simplemente, no estaban documentadas en ningún sitio accesible.

La arquitectura se mantenía a flote por pura inercia y por un sistema de alertas que notificaba rápidamente cualquier fallo en la dependencia entre servicios. Sin embargo, la latencia era abismal y los cambios eran costosos. Cada vez que llegaba un nuevo gerente o un ingeniero senior, la respuesta ante el caos era la misma: contratar más personal para intentar rehacer la arquitectura. Estos intentos siempre fracasaban.

El problema no era técnico, sino estructural. Estudiar el sistema requería años, y rediseñarlo con información incompleta era inviable políticamente. Quienes lideraban estas refactorizaciones buscaban promociones, no soluciones lentas. Al no terminar las migraciones por la resistencia al cambio, los restos de cada nuevo intento se injertaban permanentemente sobre la arquitectura existente. El headcount aumentaba, pero la calidad del código se resentía aún más.

Tres años después, un antiguo compañero de equipo le preguntó a Kehs hasta dónde llegaría ese ciclo de deterioro. Esa pregunta reveló una confusión conceptual común: mezclar la salud del negocio con la calidad del código. Una empresa puede quebrar, y el software deficiente acelera ese proceso, especialmente si el modelo de negocio depende directamente de la agilidad técnica. Pero incluso si la compañía tiene suficiente flujo de caja para tolerar la podredumbre interna, el código no se detiene. Sigue empeorando.

A diferencia de un edificio, que colapsa físicamente si le añades suficientes pisos sin cimientos adecuados, el software es abstracto. No hay límites físicos que impidan añadir otra capa de indirección, otro wrapper o reducir el rendimiento. El deterioro no es un evento discreto, sino un estado constante de colapso progresivo.

La trampa de la expectativa

Usar narrativas que sugieren un «final» o un «punto de no retorno» es peligroso para los equipos de ingeniería. Da la impresión de que hay un límite inferior de calidad que, al alcanzarse, forzará una decisión drástica. Eso no existe. El código puede volverse tan malo como sea necesario para seguir funcionando de forma insuficiente. Los grandes modelos de lenguaje no cambian esta dinámica estructural, según el autor.

La lección para quienes administramos infraestructura o lideramos equipos es sencilla pero difícil de digerir: no esperes a que el barco se hunda para actuar, porque nunca se hundirá del todo en el sentido metafórico. Solo hay un hundimiento del negocio, que puede llegar mucho después de que el código sea intratable. El mantenimiento exhaustivo y la disciplina arquitectónica no son opcionales; son la única barrera contra un deterioro infinito.